Comments on: JBoss Classloader woes, rants and redemption http://blog.kischuk.com/2004/01/26/jboss-classloader-woes-rants-and-redemption/ Just another WordPress.com weblog Wed, 19 May 2010 15:39:28 +0000 hourly 1 http://wordpress.com/ By: Anonymous http://blog.kischuk.com/2004/01/26/jboss-classloader-woes-rants-and-redemption/#comment-235 Anonymous Fri, 17 Feb 2006 12:00:20 +0000 http://rkischuk.wordpress.com/2004/01/26/jboss-classloader-woes-rants-and-redemption/#comment-235 1 1

]]> By: Norman Richards http://blog.kischuk.com/2004/01/26/jboss-classloader-woes-rants-and-redemption/#comment-234 Norman Richards Tue, 27 Jan 2004 13:40:56 +0000 http://rkischuk.wordpress.com/2004/01/26/jboss-classloader-woes-rants-and-redemption/#comment-234 Actually, you can get each of your ears to load separately by setting a loader-repository. See the XML fragment in one of my UCL rants: http://members.capmac.org/~orb/blog.cgi/tech/java/jboss_ucl.html This isn't a perfect solution, but it will keep your classes/resources from being visible outside of the ear and solve the immediate problem. Actually, you can get each of your ears to load separately by setting a loader-repository. See the XML fragment in one of my UCL rants: http://members.capmac.org/~orb/blog.cgi/tech/java/jboss_ucl.html

This isn’t a perfect solution, but it will keep your classes/resources from being visible outside of the ear and solve the immediate problem.

]]> By: Colin Sampaleanu http://blog.kischuk.com/2004/01/26/jboss-classloader-woes-rants-and-redemption/#comment-233 Colin Sampaleanu Mon, 26 Jan 2004 20:58:24 +0000 http://rkischuk.wordpress.com/2004/01/26/jboss-classloader-woes-rants-and-redemption/#comment-233 In the 3.0/3.2 versions, JBoss's classloading implementation was a completely buggy piece of crap until about the fall of 2002, when they fixed a number of horrific bugs (for example, using plain java objects from a jar that also had EJBs would cause those EJBs to deploy, etc.). From about Nov. 2002 until a month ago, I got by pretty well with an EAR setup relying on the unified classloader, which consisted of EJBs, WARs, and plain code in JARs, all listed in the application.xml, and with code being pulled in by one jar which had a manifest class-path entry referring to other code. Then all of a sudden, I crossed some magic threshold, and all hell broke loose. Multiple instances of the same class object would start showing up, resulting in classpath exceptions, when traversing EJB relations. Seemingly no way to resolve it, despite trying to change the order of various jars or similar tactivs. Then with a bit more unrelated code added to the ear, all of a sudden on each startup a randome EJB or two would be listed as illegal (with no code changed anywhere). Playing around with the jar ordering some more in a random fashion resolved that, but I still have the issue with multiple class copies. The only way I have been able to resolve that is to stop using Entity ejbs entirely, which I was halfway in the process of doing anyways. Good riddance. In short, classloading in JBoss is still royally fucked. In the 3.0/3.2 versions, JBoss’s classloading implementation was a completely buggy piece of crap until about the fall of 2002, when they fixed a number of horrific bugs (for example, using plain java objects from a jar that also had EJBs would cause those EJBs to deploy, etc.).

From about Nov. 2002 until a month ago, I got by pretty well with an EAR setup relying on the unified classloader, which consisted of EJBs, WARs, and plain code in JARs, all listed in the application.xml, and with code being pulled in by one jar which had a manifest class-path entry referring to other code. Then all of a sudden, I crossed some magic threshold, and all hell broke loose. Multiple instances of the same class object would start showing up, resulting in classpath exceptions, when traversing EJB relations. Seemingly no way to resolve it, despite trying to change the order of various jars or similar tactivs. Then with a bit more unrelated code added to the ear, all of a sudden on each startup a randome EJB or two would be listed as illegal (with no code changed anywhere). Playing around with the jar ordering some more in a random fashion resolved that, but I still have the issue with multiple class copies. The only way I have been able to resolve that is to stop using Entity ejbs entirely, which I was halfway in the process of doing anyways. Good riddance.

In short, classloading in JBoss is still royally fucked.

]]> By: Fred Grott http://blog.kischuk.com/2004/01/26/jboss-classloader-woes-rants-and-redemption/#comment-232 Fred Grott Mon, 26 Jan 2004 10:09:31 +0000 http://rkischuk.wordpress.com/2004/01/26/jboss-classloader-woes-rants-and-redemption/#comment-232 JBoss is not the only popular app server that doe sthis.. Hwoever you will be gald to know that JBOss gets anew classloader that works the way you expect.. JBoss is not the only popular app server that doe sthis..

Hwoever you will be gald to know that JBOss gets anew classloader that works the way you expect..

]]> By: Hani Suleiman http://blog.kischuk.com/2004/01/26/jboss-classloader-woes-rants-and-redemption/#comment-231 Hani Suleiman Mon, 26 Jan 2004 09:49:56 +0000 http://rkischuk.wordpress.com/2004/01/26/jboss-classloader-woes-rants-and-redemption/#comment-231 Yep, JBoss' classloader is pretty much the only one of all the appservers I've tried that has genuinely surprised me. It works in its own bizarre unique way and seems to gleefully ignore everything any spec has ever said about classloading. What's even more fun is how easy it is to clobber jboss internals with your own apps (eg, log4j). Yep, JBoss’ classloader is pretty much the only one of all the appservers I’ve tried that has genuinely surprised me. It works in its own bizarre unique way and seems to gleefully ignore everything any spec has ever said about classloading.

What’s even more fun is how easy it is to clobber jboss internals with your own apps (eg, log4j).

]]>