I think I have a solution on the Application ClassLoader (ACL) issue. ACL is
essentially the FlatCL described in the Dumbo thread.
Here is the implementation and semantics:
There is one ACL for each EAR. The ACL holds all classloaders for all EAR's
in the application.
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.
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.
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
