|> Maybe I wasn't really clear... (since you and rickard seem to miss that
|> point) the "nightmare" scenario is a "nightmare scenario" in the
|parent CL
|> case.
|>
|> It essentially says that "deploying" beans independently is a fallacy...
|you
|> need to deploy *everyone* at once (except perhaps the last one), because
|the
|> structure we use today in the container is the parent delegation one and
|> that is only done at construction time of the CL, in other
|words, we can't
|> take an already deployed bean and add the parent for that application....
|> ALLs CL are still linked to the Applications (in the XML case). There is
|no
|> "independent beans assembled independently in the runtime"...
|
|Not so fast....
Well with the Parent CL hypothesis (please read carefully :) the above is a
proof that you need to relink. (period)
The stuff below is the research we are doing (where we first abandon the
parent child delegation hypothesis:) rigor kiddo rigor)
|> I don't know that anyone in the industry has a solution to that problem
|> either? but I am wrong? does anyone out there have a solution to
|the dumbo
|> problem?
|
|:-) I think so.
|
|What we need is the "flat CL" you mentioned. And it is possible to do one,
|and keep decent classloading semantics. Basically all EAR
|classloaders would
|be regular URLClassLoaders with the system loader (=MLet loader in
|our case)
yes
|as parent. So far so good. Now, how to tie them together? By letting the
|application have a "FlatCL" that holds the set of EAR CL's. EAR CL's are
correct you get the idea,
|added to the application FlatCL as they are added or removed from the
|system. How does the FlatCL work? On loadClass() it:
|1) checks its parent CL (=system loader), i.e. normal classloader
|delegation
|2) enumerates the EAR CL's and does loadClass on each of them. If any of
|them returns a class, then return that
no, the flat CL cannot be the "initiating" class loader. If you read the ACM
paper you would see that the VM keeps a map of CLi (Initiating CL) as
opposed to the <C,Ld> wich is the defining class loader. (see paper for
semantics)
The whole trick of this level 2 construction is to expose a "initiating
class loader" and a "defining class loader" that are separate and in between
we have the "Application Class Loader" that neither defines nor initiates
class loading... ie. we can cycle independently in the sub classes because
we can keep that ACL.
I am almost there, (at least in my head :) I still don't know that it really
can work from teh bare XML
|
|And now for the last piece of crucial magic:
|Then set FlatCL as thread context classloader for the EJB's. Tada. The
|FlatCL will be used to, for example, get the classes for instances
|(=used by
|instance pools), but of course the CL attached to any given class
|will never
|be the FlatCL, since it doesn't define any classes at all. It's just a
|"spider in the web".
No again the FlatCL (ORBCl, or SetCL, or MOduleCL, or AppCL (care or a
SystemCL ;-))cannot be the instanciating CL (otherwise you never reload) so
you need to expose a URLCL as first cl and *delegate* to the ORBCL...
BeanCL->ORBCL=>(1..n)BeanCL
the first line is delegation (parent child) the second aggregation (map)
|So, now any container can access any class from any EAR in the application
|(app=set of EAR's) by simply querying the context classloader. The JNDI
|implementation uses the CCL so that'll work just fine too.
|
|The only problem left is: if an EJB instance wants another class, let's say
|it does "new Foo" then Foo will be loaded by the URL CL of the EAR
|it is in.
|Hence, it cannot access any classes in other EAR's since the parent of the
|URL CL is the system loader and not the FlatCL. So, why is not
|FlatCL simply
|the parent of the EAR URL CL's? Well, since URL CL.loadClass()
|will delegate
|to parent, which then is FlatCL, which will delegate to URL CL set, which
|will first delegate to parent which is FlatCL, which will.. etc. etc.
|
well there you go :))) that is close to what I am looking at (the problem
you are seeing has to do with initiating CL) see you are not so dumb :)
|Actually, yes: let each EAR URL CL have a FlatCL as parent, where
|the FlatCL
|has the system loader as parent, and the FlatCL delegates to the set of EAR
yup something like that
|CL's in the application *MINUS* the EAR URL CL of the current EAR! Then
|there will be no endless loadClass delegation loops, *and* there is
|consistent classloading semantics, *and* you can locate all
|classes in other
|EAR's of the application.
yes,... or register class upon entering orb... hence the map of classes
whatever
|Victory.
relax, no yet, we were there yesterday :) now I am trying to see what is
the bare minimum to define the map (application ? modules? just bare
classes?) and how the cycling logic and scope is defined
|
|There's still the little problem that the entire application must be cycled
|because of the bean-is-holding-a-reference problem.
yes and no
that is part of it, we need clear dependencies. but once we have them
a
bc
then if c changes we cycle a and c but not b (unlike a-b-c) so you already
win.
<here is what I am really looking at>
The FlatCL might not be so "Flat"
in fact the "FlatCL" can itself be a client of another "FlatCL" so that
classes in the ORB that depend on others can cycle... frankly like all
things research this is a hunch (could be poopoo) more than anything... I am
digging without really knowing at this point.
The reason is that it is fairly simple to specify "my class" needs these
classes. IN FACT the ejb-ref DOES THAT EXPLICITELY (by telling me what
classes it needs).
SO WE COULD WORK FROM THE SPEC ALONE
So I can link these classes to a map and say and what do these classes need?
so we would be looking
at
Orb
/ \b
Orb
/ \
a Orb
/ \
c d
The rules of reloading applying just like in the abc case
HEY this could be totally wrong (at least the aggregation part) it's
research...
</looking>
|
|Note that not the entire container must be cycled, it is enough that the
|caches are cleared and the pools emptied. This is a fairly lightweight
yes, trivially
|operation and the only drawback is that usage of the container will be
|somewhat slow immediately after the clearing (as the caches and pools build
|up again). But the clearing itself is pretty fast (HashMap.clear()'s
|basically).
|
|Comments?
|
nope, glad you are off the high horsey and doing investigation, you *are*
alive :) trust me I have been here many times before in my research years...
you think you are the first human being looking at something and then turns
out the Russians did it 10 years ago (in our case, the smalltalk folks
already manage complex module deployment so do the VB guys :) and we smile
stupidly... keep going almost there...
marc
PS1: it is truly an intellectual "amusement" at this point, I don't think we
will really need this in *OUR* codebase. In fact writing the deployer that
talks to these orbs is not something that I would want to spend 2 days on :)
I am happy with the classloader mechanism
PS2: now here is what is really going to blow your mind
from my "extensive databases" I believe the first trace of this dates 1999,
so someone, somewhere, probably a vendor has already looked at this ;-)
wanna change paternity of this ?
|/Rickard
|
|
|
|
|
