|>The name is really bad but I am very pleased to see the "central naming"
|>architecture. Finally we see a first take at the CL-service.
|
|do you perceive the name of the interface or the name of the
|method as being
|bad?
the name of the method
|>What were you envisioning with the URL-> cl association?
|
|My idea was that the URL under which an application is deployed can be used
|as a unique identifer ... Hence, if an application should be deployed and
|refers to an already deployed parent, the whereDeployed(parentURL) method
|should deliver non-null. Then we construct a new ClassLoader cl=new
|URLClassLoader(applicationURL,whereDeployed(parentUrl)) which will be the
|current deployment context for which you associate applicationURL-->cl.
there you deployment jars need to be aware of the URL of the others.
You are aware of classes (home remote) for ejb-refs.
Where do you propose to declare that?
|
|About class and name identity I thought that the the resulting
|classloader tree will ensure consistency and uniqueness of classes as a
|by-product (if you have the same byte-code that�s loaded through disjoint
|classloaders than these will be two different classes in the VM, hence a
|comparison for
|optimisation will fail ...)
Sure sure, that is what we are after since the beginning (same class VM def)
and keeping that association class wise is needed I just don't see it at the
URL level .
|>We finally agree and are discussing a "ApplicationManager". I am not sure
|>it is a "containerFactory" issue (you need to talk to all kinds of
|>containers) but it is at the CF layer (supra containers). The reason is
|>simple we keep a reference to all the containers that have a JNDI
|referenced
|>object we use.
|
|If you look at my last mail in response to Toby, I have stepped back from
|doing to much
|managing at the EJBJarDeployer aka ContainerFactory - but I think that in
|order to extend the its ejb-ref scope, a minimal adaption will be
|necessary.
good for you
|>We need to sit down and actually map the action of deploying an
|application
|>with many beans and some already deployed and sym linked with ejb-ref, we
|>need to define the topology (I know you guys like fancy words) of the CL,
|>and then the policies for undeploy/redeploy.
|
|I think that this is not too hard (maybe at the sacrifice of arbitrary,
|cross-application ejb-refs) - see Tobies and my attempts to define the
|necessary steps of this policy:
|
|* Deploying applications means to recursively deploy parent applications
|BEFORE.
|
|* Undeploying applications means to recursively undeploy children
|applications BEFORE.
|
|* Redeploy means undeploy, then deploy and AFTERWARDS a recursive deploy of
|the undeployed children.
|
|For this to work, we do not have to dive deeply into the code of the actual
|deployers (ContainerFactory, EmbeddedTomcat, ...) We just have to
|be able to
|link the corresponding meta-data (such as ejb-references) from children to
|parents (not vice versa) ...
Ok yes ejb-ref is a hierarchical ref, but then there are simple "shared
classes" that are completely flat... how do you deal with these (say an
argument of type "MyArgument" not an EJB).
I really believe you need class -> URL and class ->CL
marc
|>I will try to take a crack at it next week it is a service we have been
|>talking about for awhile now (level2) but never got around to doing
|
|now�s the time.
|
|Best,
|CGJ
|
|
