thanks toby for that extensive comment.
I think it�s getting much more cleaner now in the dust ...
-----Urspr�ngliche Nachricht-----
>Von: Toby Allsopp [mailto:[EMAIL PROTECTED]]
>Gesendet: Samstag, 16. Dezember 2000 13:15
>An: jBoss Developer
>Betreff: Re: [jBoss-Dev] Complex J2EE Deployment was RE: Proposed
>refactoring ...
>I agree that the exact details of how the EAR deployer finds the
>deployer for JARs or whatever can be worked out easily later.
to me, this issue appears to be a prime candidate for applying
a suitable design pattern, such as the Chain Of Responsibility or better a
Tree of Responsibility? Upon startup of the server,
a dedicated DeployerFactory could configure a suitable sequence of deployers
to divide&conquer the complex deployment process, like
J2EEDeployer(EAR)-->EJBJarDeployer(JAR)
-->WARDeployer(WAR)
OO-popes, opinions, please?
>This is the JMX interface, right? Why have the *deploy(URL) methods in
>there? For that matter, why have the *deploy(String) methods? Do we
>really need both?
the *deploy(String) are IMHO necessary to interact with the JMX interface
from
remote clients. They would be just wrappers around the *deploy(URL) methods
which do the
real work and can be used to call, e.g., the ContainerFactory from the
J2EEDeployer.
>What is the purpose of the classloader-related methods? Is this an
>alternative to using the context classloader? I'm not averse to making
>the classloader stuff more explicit, but why have both?
This would be indeed the IMHO nicer alternative to setting the context
classloader ... deploy(URL) would hence no more use the context classloader,
but rather operate like in J2EEDeployer where a completely new classloader
is constructed.
>The DeployerMBeanSupport class will just provide common services, e.g.
>converting Strings to URLs and keeping track of what's been deployed.
fully agree. Let�s see whether I could already extract some code into it ...
>I don't see any value in subclassing DeploymentException, but perhaps
>that's short-sighted.
You never know what will happen in the future ;-) Maybe just an instance of
generalomania that I�m very susceptible to.
>This chaining is the classloader consistency to allow the
>no-serialisation optimisation, right? I think that for this we want to
>stick to at most one parent (i.e. a tree).
depends on what the nodes of the tree are: single applications or sets of
interdependent applications (we have some cases here at infor, where you
want to introduce component borders although the two resulting components
are mutually dependent - that�s a question of how you organise your
development projects and how your customer rollout works in the end -
shipping the "big bang CD" versus incremental tiny updates via the WEB).
But yes, let�s stick for the moment with this "an application can have
exactly one parent application and this relation is anti-symmetric"
agreement. Should be extensible afterwards, anyway ...
>I'm not sure what you mean by "the non-cyclic recursive deployment". Do
>you mean that we have to ensure that the parent gets deployed first?
That was indeed my point. I should streamline my language a bit more. Comes
from my background in Artificial Intelligence ... you know: words,
presentations, buzzwords, colors ... and no substance ...
>I'm unclear on how we can use ejb-ref for inter-EAR dependencies. I've
>just read what I think are the relevent bits of the EJB (19.3) and J2EE
>(5.3) specs and it doesn't seem to say anything about ejb-refs that are
>resolved to EJBs from a different application. It certainly does say
>that ejb-link can only refer to EJBs in the same application.
>Are we thinking of embracing/extending this so that ejb-link can refer
>to EJBs in other EARs in the same logical "JBoss application"? Or, are
>we going to provide a way to specify this in our application-jboss.xml
>that we need for the classloader parent thing?
After reading the spec, I also could imagine why and
how to combine automatic redeployment with ejb-ref annotations.
What I could tear out of Rickards mail and what IMHO will be of good use is
that we a) have an automatic redeployment feature for "logical" applications
as you coined it and b) allow ejb-refs to work throughout those logical
applications.
>I'm not sure what ContainerFactory (should be called EJBJarDeployer?)
>has to do with EARs.
>I'm also unsure exactly what you mean by "clique".
>Can you rephrase this?
clique=a narrow exclusive circle or group of persons; especially : one held
together by common interests, views, or purposes (from http://www.m-w.com)
At least the German translation of it has a clear set-theoretic definition
... means here a set of mutually dependent applications. Since sticking to
the simpler case (see above) ...
just forget the term.
>How about this:
>1) a request to deploy an EAR is received (regard naked JARs or WARs
>as having an implicit EAR - is this correct? Or is there a global
>default EAR kind of like the default package in Java?)
Not sure about this, for naked jars and wars, you could ask the
EJBJarDeployer or the WARDeployer directly, could�nt you? Asking
J2EEDeployer could then result in an exception?
>2a) If this EAR has no parent specified then create a new "JBoss
>application" and deploy all the modules from the EAR into this
>application (i.e. they share a parent classloader)
>2b) If this EAR has a parent, deploy the parent if it's not already
>deployed and then deploy this EAR's modules into the parent's JBoss
>application. Record the fact that this EARs modules depend on the
>modules in the parent EAR.
>3) Then reploy all the modules that depend (e.g. through ejb-refs) on
>the modules we just deployed.
what about the following (which is quite similar, but more like I would
implement it):
2) if this EAR is currently deployed, undeploy it first (which results in a
tree of children applications "chld" teared down recursively).
3a) if the EAR has a parent that�s already deployed, construct a new
classloader "cl" with the parents one as parent.
3b) if the EAR has an undeployed parent, construct a new classloader "cl"
that has a its parent the resulting classloader of deploying the parent EAR.
3c) if the EAR has no parent, construct a new classloader "cl" without
parent.
4) input the application descriptor (maybe internally link the meta-data to
the parent�s one to be able to dereference througout the logical appliation)
and call deploy(url,cl) on the subordinate deployers.
5) call deploy(URL) for each of the children EARS in "chld" that have been
teared down earlier ...
>This approach eliminates the concept of an EAR application after
>deployment (i.e. treats an EAR only as collection of modules) which
>seems to be consistent with the J2EE spec, but adds a proprietary
>grouping that lasts through deploy, redploy, undeploy and affects
>internal implementation details such as classloaders and serialisation
>optimisation.
>An alternative is to put another layer in the model and keep track of
>what EAR the modules came from explictly. This information is needed
>when you decide to redeploy something due to dependencies, so it might
>be a good idea to track it explicitly. This means we have something like:
>JBoss application 1--* EAR 1--* Module
>That's meant to be showing that a JBoss application contains many EARs,
>each of which contains many modules. In this model we only need to track
>dependencies between EARs unless we want to somehow allow redeployment
>of part of an EAR.
I think that alternative two must be the choice, since we need a place to
mark which
modules must be redeployed when an application (part of a "logical"
application") is
updated, right?
CGJ
