> |> 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.
Exactly, you wouldn't be able to have two versions of a class within one
logical application. Probably overkill for, oh lets say 99% of all apps, but
I'm betting that Dr Jung might actually want this ;-)
> |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/>
Hm.. yes, that's right. Add this to the "con" side of this approach.
I agree that it would be good from the ease-of-use point of view, but as you
note there are some drawbacks.
regards,
Rickard
