> |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?
Yes.
> 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.
Nope, other way round. As you say it is not defining, hence it is not usef
for *any* class in the application. Only the EAR CL's are used as defining
classloaders. Because of this there is no problem with throwing away the EAR
CL and the classes it has created on redeploy.
> 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).
As above: DCL/ACL doesn't define any class, hence no problem.
> Rickard *please* read the paper, you keep shooting from the hip,
No, you *think* I am shooting from the hip where in reality I have fully
understood now how classes and classloader will relate to each other. I
think you should reread my initial post in this thread, but I have a feeling
you won't understand this until I show it to you in code.
> 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.
No, you're talking about having a class definition being updated temporally
while keeping the same CL. This is against all CL semantics and is bad, and
furthermore it is quite unnecessary as the ACL I described handles
versioning/updates of classes in an application without any of these
problems.
> 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
With the ACL I described this is not necessary as the dependencies will be
created due to emergent behaviour (i.e. actual usage will create
dependencies).
> so hold on Rickard I believe there is simpler and more straightforward...
Haha.. what I propose is something much simpler and straightforward, and
which doesn't have any tricky semantical sideeffects, and which doesn't
require any XML description of the dependencies.
But as I said, it seems as if I will have to show you this in code before
you believe me. Too bad.
/Rickard
