Jung , Dr. Christoph wrote:
> Hi there,
>
> I just wanted to throw in that after clearing up a few things here at
> infor and reading the ejb-ref part of the EJB2.0 spec, I�m at it and
> would like to synchronize work with Toby (and Sebastian and Daniel,
> maybe) on the issue.
>
> If you would not mind, I�ll leave this "automatic registering of
> subordinate deployment services at the J2EEDeployer" out, for the
> moment, because I
> think that after a bit of refactoring, this can be easily put in.
I agree that the exact details of how the EAR deployer finds the
deployer for JARs or whatever can be worked out easily later.
> So the first thing that is fairly easy to do, is to have that general
> DeployerMBean interface and a general DeploymentException (first
> proposal attached: main extension is that the deployers now also
> expose an un/is/deploy(URL) method, a deploy(URL,ClassLoader) method
> that explicitely takes the parent ClassLoader as an argument, and a
> whereDeployed(URL) method that returns the actual ClassLoader into
> which this part of the application has been put.)
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?
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?
[snip code very much like what I'm imagining]
> They should next be implemented/subclassed by the
> J2EEDeployer/J2EEDeploymentException, the
> ContainerFactory/DeploymentException, the
> EmbeddedTomcatService/ETDeploymentException, (whereelse should I look
> ?), and maybe that abstract DeploymentMBeanSupport that Toby and Marc
> were talking about ...
The DeployerMBeanSupport class will just provide common services, e.g.
converting Strings to URLs and keeping track of what's been deployed.
I don't see any value in subclassing DeploymentException, but perhaps
that's short-sighted.
> Third step should be the discussed chaining behaviour: I would like
> application.xml/J2EEApplicationMetaData being able to point to
> one/several "parent ears" and implement the non-cyclic recursive
> deployment there.
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).
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?
> For the ejb-ref thing, because it�s not part of the application.xml,
> we need AFAIS a recursive (un)deploy call from ContainerFactory to
> J2EEDeployer in order to get the discussed (maybe cyclic) ejb-ref
> thing working.
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?
> That�s not fully resolved now, but I think that for this purpose,
> J2EEDeployer must keep a hashtable of URL-->ClassLoader associations
> and ContainerFactory needs a map from URL to Set(URL) which is the
> clique of interdependent ears that is teared down together.
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?
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?)
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 redploy all the modules that depend (e.g. through ejb-refs) on
the modules we just deployed.
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.
Regards,
Toby.
