Rickard, DrJung,
so I am trying to put something in code.
if a,b,c are independently deployed EARs
such that
a
/ \
b c
meaning a has ejb-ref to b and c
then here are the possible CL parenthood chains from a (Cx meaning CL for x)
Ca-Cb-Cc
or
Ca-Cc-Cb
so first of all the line dependency of the delegation model is not the right
structure for the CL but also what happens when we redeploy a, b or c
Also I don't really know how we can do that since Cb already exists and we
can't "setParent" on it outside construction time... (neither on Cc for the
second)
if we redeploy a then we need to throw away Ca and we can rebuild
C'a-Cb-Cc
or
C'a-Cc-Cb
if we redeploy b then since there is no "SetParentCL" on CL we need to
redeploy
Ca (to pass it the right ClassLoader)and it gives us
C'a-C'b-Cc
or
C'a-C'c-C'b
here we see one of the first "arbitrary" problems introduced by the CL
delegation in that we need to order CL somehow and it is "arbitrary" and in
one case we need to redeploy applications just because they happen to be in
the line... (clearly not an optimal structure).
Also this "redeploy parts of it" assumes that the run-time is shut down
otherwise you are going to have live references with one old type and new
references with the new type. -> ClassCast at runtime just because you are
keeping references somewhere.
In short... this problem of keeping track of the references in memory and
what CL they come from is *impossible*, so we need to shutdown the
containerS (as in "start/stop" and clear all caches and etc etc). We need
to shutdown all containers... (imho) otherwise we can't guarantee the non
existence of "shadow" CLs.
you know just thinking as I go... I believe we need a custom CL... something
more powerful than the URLCL with Delegation... that won't work
Type has it's advantages and dis-avantages really :(
I say
1- we need to think more
2- I would keep it simple
3- Let's go for speed
marc
_________________
Marc Fleury, Ph.D
[EMAIL PROTECTED]
_________________
