the more I think about this (oh I believe I found a solution, maybe;-) the
more I realize it is a typical 99% won't use this feature. If you really
need it ? code it! but don't make the others pay for it (certainly not with
xml dependencies rickard ;-) but if not I am not even sure WL does this
right (heck a year ago you needed to *reboot* WL when you changed a class
LOL ;-)
so let's bring this to a cl-osure (pfffff) and move on, I am doing it more
out of intellectual curiousity and for fun and the pleasure of wrestling the
kiddo in the mud... (see you are wrong here and here and here :)
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Rickard Oberg
|Sent: Friday, December 22, 2000 1:37 PM
|To: jBoss Developer
|Subject: Re: [jBoss-Dev] The Dumbo problem (Big EARs)
|
|
|> |> 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
|
|
|
|
|
