« There's nothing... | Main | Updating Pro JSP for... »
20050225 Friday February 25, 2005

JBoss ClassLoader Logic Is there any logic to how JBoss puts all WARs, EARs and their accompanying JARs into the same ClassLoader? It seems logical that I should be able to deploy different versions of a JAR in different WARs. This works fine on Tomcat, but doesn't seem to on JBoss. Is there someway to turn this segmentation on? Posted in Java at Feb 25 2005, 08:00:36 AM MST 11 Comments

Comments:

Hi Matt, Welcome to the wonderful world of JBoss :-))

To answer your question : you should have a look at the "UseJBossWebLoader" attribute in your jboss-service.xml.

BTW, you might be interested by this blog entry (from my own blog) :
http://jroller.com/comments/julien.dubois?anchor=the_jboss_classloader_from_hell

HTH,

Julien.

Posted by Julien Dubois on February 25, 2005 at 08:21 AM MST #

Hi Matt, A quick Google suggests that they're doing this to make things simpler for users who can't figure out the J2ee class-loading scheme. (Although breaking it for those of use who /can/ figure out the J2ee scheme doesn't seem to woory them.) Anyway, it apparently can be switched off by setting 

<jboss-app>
  <loader-repository>unique.domain:loader=yourapp.ear</loader-repository>
&lt/jboss-app>
in your apps jboss-app.xml. See http://members.capmac.org/~orb/blog.cgi/tech/java/jboss_ucl.html & http://docs.jboss.org/jbossas/admindevel326/html/ch2.chapter.html#ch2.scopedapp.ex although I don't use JBoss myself, so can't verify it works...

Posted by Gwyn Evans on February 25, 2005 at 08:31 AM MST #

Welcome to JBoss classloader hell. Yes, it's nonsensical and absurd. The only way around it that I've found so far is the aforementioned jboss-app.xml. If you think it's bad now, just wait until you find out that precompiled JSPs (can you say index.jsp?) and resource bundles (MessageResources.properties) fall under this scheme as well. Why they believe that a hierarchal classloader would be so difficult to understand is beyond me.

Posted by Rob Kischuk on February 25, 2005 at 08:44 AM MST #

Found a more complete explanation/solution here: http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration

Posted by Rob Kischuk on February 25, 2005 at 08:46 AM MST #

Any logic, as in any compelling reason that might be accepted as valid by a consensus of experts, or just a reproducible procedure? I'll assume you mean the second. :)

1. In $JBOSS_HOME/server/default/deploy/jbossweb-tomcat50.sar/META-INF/jboss-service.xml (assuming we're talking about the "default" server), inside the <mbean code="org.jboss.web.tomcat.tc5.Tomcat5" name="jboss.web:service=WebServer"> tag, make sure <attribute name="UseJBossWebLoader">false</attribute> is present. I belive its value defaults to true.

2. In $JBOSS_HOME/server/default/conf/jboss-service.xml, ensure that the following tags are present among the mbean definitions:

   <mbean code="org.jboss.deployment.EARDeployer" name="jboss.j2ee:service=EARDeployer"><br/>
      <attribute name="Isolated">true</attribute><br/>
      <attribute name="CallByValue">true</attribute><br/>
   </mbean>
I'm pretty sure the "jboss.j2ee:service=EARDeployer" mbean is defined in there by default, but the attribute values allow classpath promiscuity by default. These values should make you happy.

I'm told the better solution is to use JBoss 4. I think it conforms to the J2EE spec by default in this regard, but we don't use it in production yet, so I'm stuck with this silliness for now.

Posted by Tim Berglund on February 25, 2005 at 09:02 AM MST #

Hey, that worked well! I tried to make the XML browser-friendly, but it didn't work too well. In any event, looks like you've got the help you need here already. Email me if you want that XML snippet in its entirety.

Posted by Tim Berglund on February 25, 2005 at 09:06 AM MST #

I fixed the XML in your comment Tim - thanks for the tip!

Posted by Matt Raible on February 25, 2005 at 09:15 AM MST #

I believe that Tim's suggested adjustment will give you EAR-level scoping, but if you have multiple WARs in the EAR, you must fuss with the web app loader, as mentioned earlier, and you may also need to fuss with the delegation model. See also: the ClassLoadingConfiguration page on the JBoss wiki

Posted by Anil Gangolli on February 27, 2005 at 09:51 AM MST #

I'm trying to configure my sar to have classloader scoping. The configuration I use in META-INF/jboss-service.xml is: <loader-repository>dot.com:loader=spmi.sar <loader-repository-config>java2ParentDelegation=false</loader-repository-config> </loader-repository> It's not working as expected. Now I'm not able to start JBoss server. The environment has JBoss4.0.3SP1 and JBoss Portal 2.2 Any idea will help. Thanks

Posted by Anbu on April 27, 2006 at 12:00 PM MDT #

Anbu: What are you trying to do? Get the UnifiedClassLoader running? I don't understand your question.

Posted by Matt Raible on April 27, 2006 at 09:26 PM MDT #

Hi all, From my experience, if you want to make your webapps to behave like with standalone Tomcat, that is, each webapp to use its own classes and/or libraries, just modify jboss-service.xml under JBoss' embbeded Tomcat. By updating JBoss' EARDeployer MBean, you're 1st isolating your deployables, so each one will have its own classloader, and 2nd forcing call by value then. In that cases, performance will decrease 10 times (as per JBoss' forum) whenever you need to call remote classes, since serialization is necessary. Besides, you'll need to provide full scheme JNDI names (jnp://localhost:1099/myComp) for your deployable components. In conclusion, you just need to tell Tomcat "do not use JBoss' UnifiedClassloader and do it as you know", and do not tweak anymore JBoss' setup. It worked fine for me. I hope it's useful... Regards

Posted by Pablo Molina on September 26, 2007 at 02:25 AM MDT #

Post a Comment:
  • HTML Syntax: Allowed