-----Urspr�ngliche Nachricht-----
>Von: marc fleury [mailto:[EMAIL PROTECTED]]
>Gesendet: Sonntag, 17. Dezember 2000 02:54
>An: jBoss Developer
>Betreff: RE: [jBoss-Dev] Complex J2EE Deployment was RE: Proposed
>refactoring ...
>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?
>I would argue that it probably needs to be at the class level
>public ClassLoader getClassLoaderForClass(String className) throws
>DeploymentException;
>or maybe even
>Same same(String JNDIName)
>This way you really ensure that you have one class loader for one class
>otherwise you still can have copies of the classes in different URL within
>one app.
>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.
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 ...)
>OK you are finally running into the "application post deployment" as I said
>you have a notion of application at deployment and assembly time (the ear
to
>be precise) but not post deployment. That is a spec problem.
>You can either have the J2EE Deployer keep that logic (today it is done
this
>way and imho sucks) or we can do it at the containerFactory level (like you
>propose).
>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.
Rather, I�d like to see this minimal interface that deployers should expose
in order to be pluggable into a more advanced application management
facility. This facility (J2EEDeployer with its restrictions today,
ApplicationManager or ApplicationDeployer tomorrow), by following a
bootstrap design, could itself be implemented as a pluggable deployer ...
>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) ...
>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
