I am trying to deploy an ear file in weblogic 12 but it gives the following error while trying to deploy the ear:
<Error> <J2EE> <BEA-160248> <Unable to parse class file: zip:D:/Weblogic/user_projects/domains/..../tmp/.appmergegen_1/lib/log4j-api-2.9.0.jar!/META-INF/versions/9/org/apache/logging/log4j/util/ProcessIdUtil.class.
<Error> <J2EE> <BEA-160248> <Unable to parse class file: zip:D:/Weblogic/user_projects/domains/...../tmp/.appmergegen_1/lib/log4j-api-2.9.0.jar!/META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.class.
I have built the project using java 1.8.0_121.Also have placed the log4j-api-2.9.0 in lib of the server.
The log4j-api-2.9.0.jar is a multiple release jar. This feature was added from JDK9. The java 8 which is present in your environment does not support it, therefore these files can not be parsed and WebLogic reports BEA-160248.
The https://docs.oracle.com/javase/9/docs/specs/jar/jar.html#Backward_Compatibility states that
The new class loading scheme is totally backward compatible with applications developed on top of the current extension mechanism. When the class loader loads the first jar file and an INDEX.LIST file is found in the META-INF directory, it would construct the index hash table and use the new loading scheme for the extension. Otherwise, the class loader will simply use the original linear search algorithm.
and according to the Doc ID 2629550.1
This message is harmless and can be ignored.
You should built the project using java 1.7. Weblogic support Java EE 7 for now.
Related
I developer a web application using Java. When I deploy it to my application server (Jetty, Tomcat, JBoss, GlassFish, etc.) throws an error. I can see this error message in the stacktrace:
java.lang.ClassNotFoundException
Or
java.lang.NoClassDefFoundError
What does this mean and how can I fix it?
What does this mean?
First, let's see the meaning of java.lang.ClassNotFoundException:
Thrown when an application tries to load in a class through its string name using:
The forName method in class Class.
The findSystemClass method in class ClassLoader.
The loadClass method in class ClassLoader.
but no definition for the class with the specified name could be found.
Usually, this happens when trying to open a connection manually in this form:
String jdbcDriver = "...'; //name of your driver
Class.forName(jdbcDriver);
Or when you refer to a class that belongs to an external library and strangely this class cannot be loaded when the application server tries to deploy the application.
Let's see the meaning of java.lang.NoClassDefFoundError (emphasis mine):
Thrown if the Java Virtual Machine or a ClassLoader instance tries to load in the definition of a class (as part of a normal method call or as part of creating a new instance using the new expression) and no definition of the class could be found.
The searched-for class definition existed when the currently executing class was compiled, but the definition can no longer be found.
The last part says it all: the class existed at compile time i.e. when I compiled the application through my IDE, but it is not available at runtime i.e. when the application is deployed.
how can I fix it?
In Java web applications, all third party libraries used by your application must go in WEB-INF/lib folder. Make sure that all the necessary libraries (jars) are placed there. You can check this easily:
- <webapp folder>
- WEB-INF
- lib
+ jar1
+ jar2
+ ...
- META-INF
- <rest of your folders>
This problem usually arises for JDBC connectivity jars (MySQL, Derby, MSSQL, Oracle, etc.) or web MVC frameworks libraries like JSF or Spring MVC.
Take into account that some third party libraries rely on other third party libraries, so you have to add all of them in WEB-INF/lib in order to make the application work. A good example of this is RichFaces 4 libraries, where you have to download and add the external libraries manually.
Note for Maven users: you should not experience these problems unless you have set the libraries as provided, test or system. If set to provided, you're responsible to add the libraries somewhere in the classpath. You can find more info about the dependency scopes here: Introduction to the Dependency Mechanism
In case the library must be shared among several applications that will be deployed on your application server e.g. MySQL connector for two applications, there's another alternative. Instead of deploying two war files each with their own MySQL connector library, place this library in the common library folder of the server application, this will enable the library to be in the classpath of all the deployed applications.
This folder vary from application server.
Tomcat 7/8: <tomcat_home>/lib
JBoss 7/Wildfly: <jboss_home>/standalone/lib
The class must exist under WEB-INF/classes or be inside a .jar file under WEB-INF/lib. Make sure it does.
Same problem happen with me.
Might be possible one of your libraries are using some classes internal which is not available
in your lib or maven dependency pom.xml.
Thats means you have analyze your error logs and identify these classes and then import all dependencies in maven or lib folder.
I have fixed this error by the same way.
because some of my libraries are using activation.jar and json.jar internally.
Is there a chance to get an information about libraries used in my java application?
Example: If I deploy my application on glassfish, the glassfish has it's own libraries and my application has own. If I use a newer version of a lib as the glassfish has, I want to test/log that my lib is used.
The reflection API lets you find some information about classes loaded into the application. For example assuming the library that includes SomeClass is loaded from a .jar file that includes version information you can use:
Package libPackage = SomeClass.class.getPackage();
String libVersion = libPackage.getSpecificationVersion();
If the .jar file does not include version information you can still find out its name with:
URL classLocation = SomeClass.class.getProtectionDomain().getCodeSource().getLocation();
I have problem with EAR module deployed in WAS6.
To support the MQ 7 features in my App. I follow the below steps:
Put Class loader policy as PARENT_LAST.
Placed all MQ 7 related jars in the root of EAR.
EAR contains Web module. When I try to start the application, I got following exception:
javax.servlet.jsp.JspException: Can't get definitions factory from context.
at org.apache.struts.taglib.tiles.InsertTag.processDefinitionName(InsertTag.java:575)
at org.apache.struts.taglib.tiles.InsertTag.createTagHandler(InsertTag.java:474)
at org.apache.struts.taglib.tiles.InsertTag.doStartTag(InsertTag.java:436)
at com.ibm._jsp._home._jspx_meth_tiles_insert_0(_home.java:106)
at com.ibm._jsp._home._jspService(_home.java:81)
The War contains the following jars.
xstream-1.3.1.jar,xercesImpl.jar, xalan.jar,struts.jar, standard.jar,commons-validator.jar, commons-net-1.4.0.jar, commons-fileupload.jar, commons-digester.jar, commons-collections.jar, commons-beanutils.jar,resolver.jar,jstl.jar, jfreechart-1.0.2.jar, jcommon-1.0.5.jar, jaxen-full.jar, jakarta-oro.jar.
EAR contains the following Jars,
com.ibm.mqjms.jar, com.ibm.mq.jmqi.jar, com.ibm.mq.jar, com.ibm.mq.headers.jar, com.ibm.mq.commonservices.jar,log4j.jar,dhbcore.jar.
And I set the class-path attribute in my Manifest file of the WAR with log4j.jar
Please anyone suggest me how Websphere's classloading policy works for where I went wrong.
Karthik
Some time ago I did something similiar. I wanted to use a specific version of a library which was already used within the WebSphere Application Server. That is the reason why you have to put your libraries in the EAR file and set the application server to PARENT_LAST class loader order.
Correct me if I am wrong, but you also have to specify your custom MQ client libraries in Manifest of your WAR file. You only mentioned Log4J. It should look somehting like this:
Class-Path: com.ibm.mqjms.jar com.ibm.mq.jmqi.jar [...] log4j.jar
Anyway, you can always check what libraries are in the Classpath of you application if you log into the Integrated Solutions Console (aka Admin Console) and check the Troubleshooting section. There is a classloader viewer. Just click yourself through the tree and check which library path are mentioned and which you would expect.
Finally, as Dylan already mentioned in his comment: WebSphere Application Server version 6.1 runs out of support September 30, 2012. :)
I'm having a hard time figuring out where the problem is coming from, so I'm posting this in the hopes that others might have found something similar to this elsewhere and are kind enough to share their insight.
I'm using a JBoss 5.0.1.GA application server running on top of a Sun Java 1.6.0-13 JDK. For the WAR file in the generated Web Service, I use a Axis2 1.4 WS engine whose JAR files are inserted by Eclipse Galileo into the project's WEB-INF/lib directory when creating the Webservice from the given "worker" class in the Dynamic Web Project. The relevant code snippet follows:
String sUrl = "http://example.com/datafile.xml";
String sPath = "/some/xpath/string";
InputStream input = new URL(sUrl).openStream();
InputSource source = new InputSource(input);
DocumentBuilderFactory docFact = DocumentBuilderFactory.newInstance();
docFact.setNamespaceAware(false);
DocumentBuilder parser = docFact.newDocumentBuilder();
Document doc = parser.parse(source);
XPath xpath = XPathFactory.newInstance().newXPath();
// error occurs here:
String result = (String) xpath.evaluate(path,doc,XPathConstants.STRING);
input.close();
This is the error I'm getting from the JBoss log:
java.lang.LinkageError: loader constraint violation: when resolving field "STRING" the class loader (instance of org/jboss/classloader/spi/base/BaseClassLoader) of the referring class, javax/xml/xpath/XPathConstants, and the class loader (instance of <bootloader>) for the field's resolved type, javax/xml/namespace/QName, have different Class objects for that type
I could use the XPath.evaluate(String,Document) — however there are occasions where I need to get (for example) a XPathConstants.NODESET instead, so it's a no-go. I have also tried to fumble a little by littering some jboss-web.xml files here and there in the WAR file, but with no effect.
What I'm trying to understand is:
Where could the error be coming from? The JBoss class loader? Some weird interaction between JBoss and the Sun JDK? Some weirdness introduced by Eclipse when creating the Web Service? Maybe some confusion introduced by the Axis2 libraries deployed within the WAR?
I've found instances of compiled class files in what looks like a triple-whammie:
Sun JDK (file rt.jar);
JBoss libraries ($JBOSS_HOME/lib/endorsed/stax-api.jar); and
Axis2-deployed libraries ($JBOSS_HOME/server/deploy/MyProject.ear/MyProject.war/WEB-INF/lib/axis2-saaj-api-1.4.jar and woden-impl-dom-1.0M8.jar).
How exactly am I supposed to configure JBoss to tell it which classes it's OK to load from "other" libraries from? Specifically, the jaxax.xml.namespace.QName is is causing the grief.
Thank you in advance.
JBoss will throw a LinkageError when the application's classpath contains classes which JBoss considers "protected", i.e. it does not permit the application to contain its own copies of certain key APIs.
In this case, it looks like your appcontains its own copies of the javax.xml.xpath API, and possibly some others as well, as you mentioned.
You need to remove anything from your EAR/WAR's lib directories that clashes with JBoss's own libraries (e.g. axis2-saaj-api-1.4.jar).
It seems that the problem was solved by removing the javax.xml.namespace.* package and respective classes from the deployed Axis2 JAR files. Namely, using Axis2 1.4.1 (instead of 1.4), I repackaged these JAR files:
axis2-saaj-api-1.4.1.jar, by removing javax.xml.namespace
woden-impl-dom-1.0M8.jar, by removing javax
Also, Eclipse is extremely picky at the project configuration. So far, I've found that the Project Facet for the Dynamic Web Project has to be created with a Dynamic Web Module of version 2.4 (and not 2.5 as it suggests by default), but with a Java version 6 (same as the branch of the used JDK). I don't know why this happens, I suppose the Dynamic Web Module version 2.4 tying up by default with Java 1.4 in Eclipse is where all the confusion comes from. Some googling led me to believe that package javax.xml didn't become incorporated into the JDK until Java 5 or Java 6 -- hence the possible mixup! However, I'm not knowledgeable enough to investigate if the problem comes from how Eclipse packages the archive files for deployment so this is just a suspicion I have so far.
I have an application that is running Jaxb 2.1.12. I am running JDK 1.5 and OC4J 10.1.3.4.0. When I try to use the portion of my application that is using Jaxb, I get the following error:
Unable to locate jaxb.properties for package
I narrowed this down to the xml.jar that comes with OC4J. It contains Jaxb 1.0 classes. I can fix this error by adding the following to the orion-application.xml file:
<imported-shared-libraries>
<remove-inherited name="oracle.xml"/>
</imported-shared-libraries>
The problem is that I am deploying the WAR file to OC4J by using the admin_client.jar utility. I do not have an EAR to put the orion-application.xml file in, so I decided to try adding the orion-web.xml file to the WAR's WEB-INF directory and setting the search-local-classes-first property to true:
<?xml version="1.0"?>
<orion-web-app
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/orion-web-10_0.xsd" deployment-version="10.1.3.4.0"
jsp-cache-directory="./persistence"
jsp-cache-tlds="standard"
simple-jsp-mapping="false"
temporary-directory="./temp"
schema-major-version="10" schema-minor-version="0" >
<web-app-class-loader search-local-classes-first="true" />
<web-app>
</web-app>
</orion-web-app>
This causes the application to not deploy at all. I get an error saying that the Spring configuration files cannot be parsed. I would like to use search-local-classes-first. How can I use this property? Also is there a way that I can deploy the orion-application.xml file with the WAR file?
09/11/16 13:26:01 WARNING: DeployerRunnable.run Unexpected exception parsing XML document from Servl
etContext resource [/WEB-INF/applicationContext-acegi-security.xml]; nested exception is java.lang.C
lassCastException: oracle.xml.jaxp.JXDocumentBuilderFactoryoracle.oc4j.admin.internal.DeployerExcept
ion: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/applicationCon
text-acegi-security.xml]; nested exception is java.lang.ClassCastException: oracle.xml.jaxp.JXDocume
ntBuilderFactory
at oracle.oc4j.admin.internal.DeployerBase.execute(DeployerBase.java:126)
at oracle.oc4j.admin.jmx.server.mbeans.deploy.OC4JDeployerRunnable.doRun(OC4JDeployerRunnabl
e.java:52)
at oracle.oc4j.admin.jmx.server.mbeans.deploy.DeployerRunnable.run(DeployerRunnable.java:81)
at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledE
xecutor.java:303)
at java.lang.Thread.run(Thread.java:595)
Note: I do not get this error with Java 1.6 and I believe that is because 1.6 comes packaged with Jaxb 2.
If creating a ear file solves the problem, I recomend you go this way. Also, when you deploy a war file, the container creates an ear for you. Check in the applications directory of the oc4j's install dir for the ear file.
In the documentation for "search-local-classes-first" I saw the following line:
In accordance with the servlet specification, search-local-classes-first functionality cannot be used in loading classes in java. or javax.* packages.*
Since, JAXB2 is included in JDK 1.6 and is now under javax.*, maybe the appserver ignores the classes/library even though it is present in the WEB-INF/lib directory. Try putting the JAXB jars in your $JRE_HOME/lib directory. If it is picked up, then you can try modifying the startup scripts for your appserver to include the JAXB jars in the primordial classpath.
The solution is a bit of a hack :). Here's a link with steps for doing the same thing for Apache CXF.
Replacing JAXB with JAXB2.0 in OC4j