We use Jboss 5.1 in which we deploy several of our applications. Now, Jboss has a version of hibernate jars in its common/libs. One of our application uses a newer version of hibernate jars. So, we had the dependency jars packaged in the war that gets deployed in Jboss. The application gets deployed fine, but when we try hitting in, it throws the below exception.
My suspicision is that Jboss is using its own version of hibernate jars, but not the ones packaged in the war....How do i make Jboss uses the hibernate jars that come from the war but not from its common/lib
I prefer to make a change in the concerened application, but not in Jboss as there are several other application which live in the same Jboss instance and I do not want to mess them up by modifiying jars in jboss/common/lib
SEVERE [ContainerResponse] The exception contained within MappableContainerException could not be mapped to a response, re-throwing to the HTTP container
java.lang.NoSuchFieldError: INSTANCE
at org.hibernate.type.StandardBasicTypes.<clinit>(StandardBasicTypes.java:45)
Java EE class loaders are a hierarchy:
Bootstrap
App server
Application
Since the app server class loader finds its version of the Hibernate JARs first, your app is out of luck.
You have to tell JBOSS to prefer application class loader JARs. Google for the config to do so; I don't remember it.
check this link out.. http://huima.wordpress.com/2011/09/16/having-fun-with-jboss-classloader-or-how-i-figured-out-how-to-get-my-application-to-work-in-jboss-5/
there are other links inside the article that explains JBoss class loading in detail, which you could check out as well.
The way I have done it before is by adding jboss-classloading.xml inside WEB-INF of the war with the below contents
<classloading xmlns="urn:jboss:classloading:1.0"
name="yourapp.war"
domain="IsolatedDomain"
import-all="false"
parent-first="false" >
</classloading>
Related
Background-I am trying to deploy a custom jar to the Tomcat 8.x lib("${catalina.home}/lib") folder. Per Tomcat documentation, it should be picked up when the server starts(via common classloader), and classes(from the jar) are made available to Tomcat and other apps deployed on it. However, I have an app deployed on Tomcat which is looking for the classes from this jar, but it fails with NoClassDef found error.
What I have done so far- I have tried to look at the classes deployed by using -verbose:class but am unable to find the class(es) from the jar. It appears that tomcat ignored the custom jar(yes- I understand all the classes are not loaded at the startup rather they can be 'found' using delegation pattern at runtime). To test that tomcat is working per documentation ie autoload from 'lib' folder, I threw in the ojdbc.jar in the same lib folder. Voila- I could see it loading some classes from the ojdbc jar(at this stage,my code doesn't need ojdbc.jar or classes from it).
Need help -- I am unable to understand why tomcat is ignoring my custom jar, while it deploys ojdbc.jar(at a theoretical level it is also custom as it is not bundled with tomcat) ?
I have two WAR files that i need to deploy on a server.
the catch is that i cant run another tomcat on that server.
deploying two WAR files is easy but, is it possible to run them both while one of them uses
Spring 3.8
and the other one uses
Spring 4.1.4
which is the latest version?
Will it conflict?
answers like "try it out" are acceptable :) but i need to know for sure so i wont have issues in the future.
Thanks
See the following for an explanation of how Tomcat's classloading mechanism works:
http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html
WebappX — A class loader is created for each web application that is
deployed in a single Tomcat instance. All unpacked classes and
resources in the /WEB-INF/classes directory of your web application,
plus classes and resources in JAR files under the /WEB-INF/lib
directory of your web application, are made visible to this web
application, but not to other ones.
If, then, the Spring Jar files are bundled in WEB-INF/lib for each application then you will have no issues. An issue would only arise if they were in some shared location.
two different application under tomcat has two diffferent classpath and classloader so they don't conflict
latest as of today is 4.2.0 (under dev), you can keep track at http://projects.spring.io/spring-framework/
I have web application which has a servlet and an ejb. The ejb is annotated #Local. In my servlet I used #Inject to inject the ejb. It woekd fine.
Then I created an ear with an ejb module and a web module. I deployed the ear and I got exceptions. Then I learned that I cannot use #Inject. So I used #Resource(lookup = "jndiname") and then it worked.
Then I created an independent web application and used the #Resource annotation to inject the ejb in the ear into a servlet. The war failed to load. So I thought to place the ejb jar inside the lib directory of the app server so that all applications in the app server can use them. I am using jboss eap 6.0. I placed the jar under jbosshome/modules/com/ejb/beginner/main/. It did not work. I got exceptions. Then I placed the ejb jar in jbosshome/modules/com/ejb/beginner/api/main/. Still no luck.
I want to learn how to create #Local beans so that applications in the app server can use. Is it possible?
I figured it out. If I want to use modules from another ear in other deployments I have to declare the dependencies in the MANIFEST.MF file like this
Dependencies: deployments.appname.ear.appname.jar
The following links help me figure it out
https://community.jboss.org/message/604576
https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7
I have a Spring webapp running in Glassfish 3.1.2. I am just beginning to convert the webapp to OSGi. I undeployed the existing webapp and copied the spring and gemini OSGi jars into the modules directory in the Glassfish installation. I then installed and activated them using the Glassfish OSGi web console (which I understand to be some sort of customised Felix web console) and everything was fine. It didn't do anything but I could install and activate them in the web console which is what I wanted to test.
I then started to redeploy the non-OSGi jars of my existing webapp using the Glassfish Application console to see if the 2 type of jars could coexist, which, given my understanding of OSGi I thought they should be able to. At this point NoClassDefFoundErrors started getting thrown complaining about not being able to find org.apache.commons.logging amongst other classes. These class were present in both the Module directory as the installed OSGi jars and the application classpath. I then deactivated the jars in the console but didn't remove the the OSGi jars but the exceptions continued to be thrown.
I got a classloader print out and found that the jars in the WEB-INF of my webapp weren't getting loaded but I wasn't sure whether this was the problem or a symptom.
I then removed the jars from the uninstalled the OSGi jars and everything started working again and the webapp could be deployed.
Can anyone think of any reason why this might happen? I am guessing that the content of the module directory is on the classpath but if so why? How would I prevent this from causing problems if I want OSGi and non-OSGi jars to work together?
Side Notes
When I viewed the classes getting loaded by the classloader I couldn't see content form the modules folder getting loaded.
I can install and activate the OSGi jars after the the non-OSGi jars are deployed but not the other way round.
( Disclaimer: I do not have specific experience with glassfish, but JBoss and other
strange environments sporting classloader hierarchies)
You have to be carefull with classloader hierarchies in java - the same bytecode equal class will not be equal or asignable to if comes from another classloader, and while loading classes it is important to find dependencies through loading classloader or his parents.
To resolve your situation you will have to carefully examine this hierarchy and check settings for delegation and class resolution ( like parent first / self first ).
JBoss tried to solve this problem by introducing unified classloader which resulted in one big pile of assorted classes and leaks of resources between contexts / webapps in default setting.
JBOSS is throwing a:
java.lang.NoSuchMethodError: org.w3c.dom.Document.getDocumentURI()Ljava/lang/String;
Error when loading a wsdl. Can I configure it to prefer the library in my WAR instead of the system or app server lib?
The app server should already be using any JARs in WEB-INF/lib, along with the system and app server library paths - the standard approach to this is that the ClassLoader for WEB-INF/lib delegates class loading to the app server lib, which delegates class loading to the server lib, and only if the parent classloader cannot find the class does it attempt to load it's own classes.
In other words, if you place the same class in WEB-INF/lib and the app server's lib, the latter JAR will always be used. This means it is possible to create conflicts by having classes with the same names but different versions available in both WEB-INF/lib and the app server's lib - are you sure this isn't what's causing your issues? Can you resolve the conflict?
Some app servers (not sure about JBoss, but I know WebSphere allows it) lets you configure the classloader so that the child loader is checked first (child-first vs parent-first), but this type of configuration can cause other issues.