Comments on: The JBoss ClassLoader is pain incarnate http://blog.kischuk.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/ Just another WordPress.com weblog Wed, 19 May 2010 15:39:28 +0000 hourly 1 http://wordpress.com/ By: Rob Kischuk http://blog.kischuk.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-243 Rob Kischuk Fri, 23 Jan 2004 15:16:45 +0000 http://rkischuk.wordpress.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-243 My point is that my preference is to NOT share resources between web apps or EARs, but that seems to be the default behavior in JBoss. In JBoss, webapp2 seems to try and use webapp1's classes if webapp1 loaded them first. I fail to see the benefit here - seems like a recipe for disaster. My point is that my preference is to NOT share resources between web apps or EARs, but that seems to be the default behavior in JBoss.

In JBoss, webapp2 seems to try and use webapp1′s classes if webapp1 loaded them first. I fail to see the benefit here – seems like a recipe for disaster.

]]> By: Anonymous http://blog.kischuk.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-242 Anonymous Fri, 23 Jan 2004 14:55:32 +0000 http://rkischuk.wordpress.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-242 It is possible, as shown in the blog entry. Same application multiple times, different resources. These are completely isolated classloaders. It is possible, as shown in the blog entry. Same application multiple times, different resources. These are completely isolated classloaders.

]]> By: Pawn http://blog.kischuk.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-241 Pawn Fri, 23 Jan 2004 14:32:17 +0000 http://rkischuk.wordpress.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-241 From the spec.... The deployment tool must allow the Deployer to deploy the same J2EE application multiple times, as multiple independent applications, possibly with different configurations. For example, the enterprise beans in an ejb-jar file might be deployed multiple times under different JNDI names and with different configurations of their resources... With Jboss class loading scheme I do not believe this is possible. From the spec…. The deployment tool must allow the Deployer to deploy the same J2EE application
multiple times, as multiple independent applications, possibly with different
configurations. For example, the enterprise beans in an ejb-jar file might
be deployed multiple times under different JNDI names and with different configurations
of their resources… With Jboss class loading scheme I do not believe this is possible.

]]> By: Pawn http://blog.kischuk.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-240 Pawn Fri, 23 Jan 2004 14:25:44 +0000 http://rkischuk.wordpress.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-240 This problem has crop up in so many places where each victem of this is usually comming from commercial giants such as weblogic or webshpere and usually they spend hours racking thier head trying to figure out why things are just out of whack. It's in the spec and there is even documentation on how to share resources between applications through the extension mechanism. Take a look at this link if you would like more information on j2ee classloading. It's one of the best I've seen, quick to the point with some links to other good references. http://www.theserverside.com/articles/article.jsp?l=ClassLoading This problem has crop up in so many places where each victem of this is usually comming from commercial giants such as weblogic or webshpere and usually they spend hours racking thier head trying to figure out why things are just out of whack. It’s in the spec and there is even documentation on how to share resources between applications through the extension mechanism. Take a look at this link if you would like more information on j2ee classloading. It’s one of the best I’ve seen, quick to the point with some links to other good references. http://www.theserverside.com/articles/article.jsp?l=ClassLoading

]]> By: Anonymous http://blog.kischuk.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-239 Anonymous Fri, 23 Jan 2004 13:28:54 +0000 http://rkischuk.wordpress.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-239 webapp1 and webapp2 can use parallel resources like the author just showed above. webapp1 and webapp2 can use parallel resources like the author just showed above.

]]> By: Anonymouse http://blog.kischuk.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-238 Anonymouse Fri, 23 Jan 2004 13:17:53 +0000 http://rkischuk.wordpress.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-238 The JBoss CL does suck. It's reason enough to go and buy a real appserver. The JBoss CL does suck. It’s reason enough to go and buy a real appserver.

]]> By: Anonymous http://blog.kischuk.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-237 Anonymous Fri, 23 Jan 2004 13:14:37 +0000 http://rkischuk.wordpress.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-237 Um, if webapp1.war has struts, you DON'T WANT webapp2.war to use webapp1's classloader. You want webapp2 to have its own parallel resources. Really. Um, if webapp1.war has struts, you DON’T WANT webapp2.war to use webapp1′s classloader. You want webapp2 to have its own parallel resources. Really.

]]> By: Anonymous http://blog.kischuk.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-236 Anonymous Fri, 23 Jan 2004 12:56:46 +0000 http://rkischuk.wordpress.com/2004/01/23/the-jboss-classloader-is-pain-incarnate/#comment-236 Isolate packages and people complain that the performance sucks, don't isolate and people complain that their packages are not isolated. Whatever. Classloaders are pluggable, write your own. Isolate packages and people complain that the performance sucks, don’t isolate and people complain that their packages are not isolated. Whatever. Classloaders are pluggable, write your own.

]]>