[EMAIL PROTECTED] wrote:
You do know you can turn that off or scope it. You can decide just which packages share what and even do it in pyramids.
The extent of my understanding of this is as follows: (note: It's entirely possible / likely that I do NOT understand this correctly at all).
1. By default all classes in all deployed ear files are loaded by a common classloader.
2. You can tell JBoss to use a separate classloader for each deployed ear by using a <loader-repository> element in in jboss-app.xml
3. classes contained in jar files dropped into the deployment directory appear to be loaded "up" the classloader hierarchy when using the option from (2) above.
I'm guessing there is a lot more to the <loader-repository> element config that what I'm currently aware of... but that's just a guess.
The real kicker is that while we need to share class definitions for performance, we also need to split up our packaging for uptime and maintenance (meaning I don't want to bring the whole system down just to redeploy one ejb). However that has some nasty classloader implications as well. You can get it right once you understand how it all works. Its really not that difficult or troublesome once you understand how it works.
I already understand a little more than I did a few weeks ago, when I
was about to give up on JBoss entirely due to classloader issues... now, while I am sure I could still learn a lot more on the issue, I understand enough to get past the problem I was having.
Maybe at some point I could give a talk on how to package and set up your classloader repositories....and walk through the classloader code. That=B9s probably 2 hours worth. Is August open?
Are you referring to doing a Tri-JUG presentation on said topic? If so, that would be excellent, IMO.
TTYL,
Phil
_______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://mail.trijug.org/mailman/listinfo/juglist_trijug.org
