|> 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.
that is already done today, with JNDI linking.
We are talking about a central manager.
|
|> 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.
|
|:-)
again that is already done in jboss.xml (please check out DTD)
we are looking at a central place to manage these relations outside the xml
file
|> > 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*.
... the *real* reason ;-) is that a Container Factory is a Container
Factory is a COntainer Factory, the supra container notion that we have that
can deal with applications is nothing yet.
|> I'm not sure what ContainerFactory (should be called EJBJarDeployer?)
|> has to do with EARs.
|
|I agree, it shouldn't deal with EARs.
Our CF deals with JARs, if we had a CF to deal with servlet/jsp on a per
bean basis (like we do) then it would need to deal with WARs. Whether we
create a ApplicationContainerFactory that deals with EARS or not is
packaging, but the "deal" with ears at a supra-container level is obvious.
|> 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.
.... mmm You make the same point as Dr Jung... frankly I don't see it, but
can you explain? will buy it ;-)
I am thinking "ease of use, ease of use"... can't a deployer see that it is
a JAR and tell you "kid, thank you for bringing me this (<private>moania!
why? thank you Rickard!</private>) but I am not the one to deploy it let me
delegate it for you to the Jar deployer"... you see where I am coming from ?
this way you don't require that people package an ear structure everytime...
|> 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.
yes
|> 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>
read my mail to Dr Jung either you specify the URL either you work from the
class description (ejb-link spec) with a CL service at the class level.
You can then infer that url...
but I am open to that actually specifying the URL will be messy but clear
and a beginning to this ...
| </application>
| <application>
| <name>Bar</name>
| <url>http://.../bar.ear</url>
| <parent>Foo</parent>
| </application>
|</system>
ok, really, why the system tags...
system is system and application is application...
<system><application/></system> makes no sense to me
Finally does this cover the dependent classes ?
|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.
what he is proposing is not really the system idea... see above...
What he is proposing is
<application>
<module>
<ear/>
</module>
</application>
which is a more powerful way to scope the application and provide
subparts...
Some links are "parent" links (the class loader dependency) some others are
just "shared classes". I don't think he says so explicitely at this point.
I believe we need to sit down and actually do it to see the thing in all its
scope.
|> 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.
|
I don't really follow... the J2EEDeployer needs a rewrite, let's do it...
what is the "standard" stuff...
marc
|/Rickard
|
|--
|Rickard �berg
|
|Email: [EMAIL PROTECTED]
|
|
