Hi!
Toby Allsopp wrote:
> 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"?
Yes.
> Or, are
> we going to provide a way to specify this in our application-jboss.xml
> that we need for the classloader parent thing?
Yes.
:-)
Both are useful I think, but the first would be recommended since it is
easier from a deployer point of view.
> > 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.
All of what we have talked about should be done through the J2EE
deployer, and not the ContainerFactory. The ContainerFactory *does
things* whereas the J2EEDeployer decides *what should be done*.
> I'm not sure what ContainerFactory (should be called EJBJarDeployer?)
> has to do with EARs.
I agree, it shouldn't deal with EARs.
> 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?)
It should be possible to deploy single JARs, but then you're "on your
own". I would mandate EARs for this more complex scheme to work.
> 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)
Correct.
> 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.
That won't work well. To do the above the parent link would have to be
in the form of a URL (otherwise, how would you know where to get the EAR
to deploy?). I would prefer if it is only a name. If the parent is not
deployed then the deployment of the child *fails*. Plain and simple.
First deploy parent. Then deploy child. If parent redeploy -> child
redeploy.
We could probably do a "large application" XML description containing
things like:
<system>
<application>
<name>Foo</name>
<url>http://.../foo.ear</url>
</application>
<application>
<name>Bar</name>
<url>http://.../bar.ear</url>
<parent>Foo</parent>
</application>
</system>
so that it is easy to deploy them initially. Somewhat like a script.
After that parts of the app can be cycled as usual.
> 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
Somewhat like the "system" outlined above. Yes, that might be a good
idea.
> 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.
The good thing about the above is that we can probably add a
SystemDeployer that is "on top" of the J2EEDeployer even, so we don't
mess with the standard stuff.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
