> 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.
Not exactly. Every top level deployment (thing in
$JBOSS_HOME/server/$CONFIG/deploy) gets its own classloader. The
classloaders themselves are linked into a "Classloader Repository" and the
"parent-child delegation model" is used.
Meaning if your classloader is first to load the class it is linked as the
classloader for that class in the classloader repository. The next
classloader that tries will check to see if it has ever loaded the class
locally and then ask the classloader repository. The classloader repository
will return a reference to the first classloader which will then be used to
serve up the class.
This is done this way because we need a classloader in order to cycle the
deployment but in java2 classes are defined at runtime by classloader+FQN.
Meaning two instances of Foo loaded by two different classloaders are NOT
the same class, will fail casts and instanceof.
So you can have separate classloader repositories that don't share classes.
You can even have hierarchies. Meaning
A
B C
A shares with B, A shares with C but since B and C do not share with A,
classes in C can't be seen in B.
Any EJB deployment associated with C that wanted to talk to B would have to
over-ride the interceptor stack with the ByValueInvokerInterceptor (default
is InvokerInterceptor which tries to pass by reference). This would be slow
but they won't share classes so they have to serialize state...
Clear as mud?
JBoss supports arbitrary "Russian doll" deployments. Meaning a Jar can
contain an EAR which could contain a SAR which could contain another EAR.
So you literally can just package everything up on one big xAR. However if
you want maximum hot deployability you have to consider the classloader
implications.
Consider this:
Aejb-jar.jar has FooBean, FooLocal, FooLocalHome
Bejb-jar.jar has BooBean, BooLocal, BooLocalHome
If both are in the deploy directory, they can talk turkey and regardless of
whether its remote or local they'll pass by reference (default behavior of
3.2.x and even earlier). However consider this. If I redeploy Bejb-jar.xml
it gets a new classloader and the reference to the old classloader is
removed from the classloader repository. So now when A tries to cast the
lookup to (BooLocalHome) you'll get a class cast exception. Why? It kept a
local cache (because it would be ungodly slow to ALWAYS go to the
Classloader repository) of the class def. So what can I do? Well I can
always cycle them together. I can ear them up into one deployment (thereby
always cycling them together... But A didn't change...so why should I!!!
So correct is to:
Aejb-jar-contract.jar has FooLocal, FooLocalHome
Aejb-jar.jar has FooBean
Bejb-jar-contract.jar has BooLocal, BooLocalHome
Bejb-jar.jar has BooBean
(yes this will work due to implicit deployment ordering, but we could make
it explicit)
Now if I change FooBean or BooBean and the interface (contract) doesn't
change, I'm good to go because neither has a reference. (and you don't
implement the interfaces with EJBs --remember-- so they aren't needed in the
same classloader). If I change the contract, well I have to recompile
everything anyhow so I'd need to cylce them both anyways.
Nirvana for deployability are MBeans that only pass back primitives..
Clear as mud? Classloading is inherently difficult, but once you understand
the basics it gets simple.
>
> 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
>
No, you can create MULTIPLE classloader repositories and tell the deployment
in either jboss-app.xml (EAR), jboss.xml (ejb-jar), jboss-service.xml (sar)
or MANIFEST.MF to use a different loader repository. If you go look in the
JMX console you'll see that everything is in the DEFAULT classloader
repository (identified by an MBEAN).
> 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.
Huh?
> Are you referring to doing a Tri-JUG presentation on said topic? If so,
> that would be excellent, IMO.
Yes. It would be good if August is open because I know I'll be in town
since I'll likely be one of the instructors at the JBoss Advanced Training
the following week.
-andy
_______________________________________________
Juglist mailing list
[EMAIL PROTECTED]
http://mail.trijug.org/mailman/listinfo/juglist_trijug.org
