|> Is this really true? Would it not be possible to figure out what classes
|> need to be shared from ejb-refs and then pull all of those out of the
|> individual EARs (so that they're not picked up by the leaf classloaders)
|> and put them in the logical application's parent classloader?
|
|No, because it might also be the case that you *want* class duplication
|in parallel subtrees (for versioning). I.e. two EAR's can communicate
|through a parent EAR's classloader but they both have their own versions
|of a class that the parent EAR does not have.
Then define "current version" and have that class be the right one.
|Also, there's still the fact that you cannot dereference ejb-links
|without knowing in which EAR's to look. If you say "look in all deployed
|EAR's" then that means that you can only have one application deployed
|at any one time, since two applications may have beans with the same
|EJB-name.
he is not saying that, he is saying given a ejb-ref (and the class that goes
with it per spec) we can look up a EAR (you keep that in the
ApplicationManager) and infer the right one... it is STILL fucked up since
we can't "undeploy" the app just because someone is deploying something on
top and we need the silly little CL to be redeployed because of setParent()
being only at construction time...
<frustration/>
marc
|
|/Rickard
|
|--
|Rickard �berg
|
|Email: [EMAIL PROTECTED]
|
|
