|When an EAR is deployed the ACL is set as parent of the EAR CL being
|deployed. Then an EJB CL is created with the EAR CL as parent, and the EJB
|CL is used as contextclassloader (CCL) as usual. So we have EJB CL->EAR
|CL->ACL.
3 levels?
|When an EJB container or EJB needs a class it will use the CCL. Normal
|delegation is used so parents are checked first. This eventually gets us to
|the ACL and the following implementation is used:
|* loadClass of ACL is not changed (i.e. the default "check cache, check
|parent, findClass" is performed)
|* findClass in ACL (which is called if the parent does not have the class)
|takes the set of EAR CL's and query them on *findClass* (NOT loadClass,
|which would delegate back up to the ACL). If the EAR CL has the class it
|will be returned. We then add the class to the ACL class cache.
|That is all that has to be done in ACL (same for getResource of course).
|Next time loadClass is called for the same class we will use the class in
|the cache, but this is merely an optimization.
|
|The only needed change now is that the EAR CL must make findClass
|public (it
|is normally protected) so that the ACL can call it.
|
|With this we are basically done. This will allow sharing of classes between
|EAR's in the same logical application. So, the question remaining is: why
|one ACL per EAR and not simply one for the whole application?
|
|The reason is that the ACL class cache now holds the EAR dependencies! If
|EAR 1 used a class from EAR 2 the ACL for EAR 1 will have the classloader
|with EAR 2's classloader in it. So, if EAR 2 is redeployed we can then
|figure out that EAR 1 needs to be restarted since it used classes from EAR
|2.
|
The Application Class loader idea doesn't need to follow CL rules since it
is never seen as initiating or defining. In other words we can dynamically
send back the right class with the old ACL. Also the "Application" moniker
(even though I banged on you to use for other objects) is not the right term
here. I prefer a "DependencyClassLoader" and it is given for ***EVERY***
class in the application.
These DCL don't cover the "application", just the Dependency of the given
class. Simple and straight forward, see my previous dumbo post for the
structure this DCL takes.
The only thing that is not clear in my head this morning is if the VM will
allow temporal discrepencies in the class the DCL return (same DCL new
class).
Rickard *please* read the paper, you keep shooting from the hip, it
describes *in depth* the problem of constraints to defeat exactly the kind
of thing we are discussing,i.e. returning different classes from the same CL
through delegation (it is called "temporal consistency" or the fact that a
CL even delegating will always return the same class over time, preventing
Cast problems in your code). The trick here, I believe is that our DCL is
never controlled or called by the VM (never initiating or defining) so he is
never tracked.
With that in place we have a simple 2 level architecture (hence the level 2
moniker) and WE DON"T NEED TO SPECIFY ANYTHING IN XML FOR EJB-REF and for
dependent objects we can require that the developer say "I depend on this
class for my interfaces". ie
<jboss.xml>
<dependency>
<class> org.myorg.MyClass</class>
</></>
and we keep this map in a naming DCL service.
so hold on Rickard I believe there is simpler and more straightforward...
gotta go do some christmas shopping and the "constraints" problem is only in
the VM so I can think all I want about it, until I actually code it we won't
know for sure. I believe I will be done tonight...
marc
|We are done.
|
|The only metadata needed for this is that the EAR's must say which logical
|application they are part of. The simplest hack would probably be
|to require
|that the application name in the EAR's application.xml must match, i.e. if
|there are several EAR's with the same name they belong to the same
|application.
|
|Comments?
|
|/Rickard
|
|
|
|
|
