Hi!
Mike wrote:
> >From what I can tell, jBoss treats individual .jars w/in an .ear as a
> separate applications.
Yup, currently this is true.
> Is this intended behavior?
Well, it's the intended behaviour of the current code, but the current
code aint right if that's what you mean :-)
> Specifically, I need to
> use the ejb-link tag to link two beans, each in separate .jars of the same
> .ear (legal, according to section 14.3.2 of the 1.1 spec). To this end, I
> propose the following refactoring of ContainerFactory:
> add method createContainer( BeanMetaData bean, URL url ) - isolate
> responsiblity for container creation (basically, move the guts of the
> current deploy( URL ) method here)
> add method deploy( URL app, URL[] jars ) - deploy all jars to a single
> application (@app is simply used for application identification), initalize
> and start the application; delegates majority of work to createContainer()
> modify method deploy( URL url ) - basically, just call deploy( url, new
> URL[]{ url } )
Nah, the discussions re: Complex deployment will take care of this case.
Basically a "deploy(URL, ApplicationMetaData)" method will be added to
allow this.
> Also, the J2eeDeployer would need slight mods - the various deployment
> methods (startApplication, stopApplication, checkApplication) would need to
> make a single invocation to the ejb deployer (a.k.a. ContainerFactory)
> rather than a separate invocation for each .jar.
Yes.
> Rationale - the meat of ContainerFactory is the createContainer(..) method;
> it's responsibility should be creation and initialization of the bean
> Containers, not initialization/starting of an Application. I really don't
> like having the deploy( URL, URL[] ) method; the responsibility for
> application deployment IMHO doesn't belong in ContainerFactory, but until
> ya'll get the whole system/application deployment worked out (ala the
> Complex J2eeDeployment...thread), I think it's the simplist solution.
Yeah, the CF needs more methods to give us a better lifecycle model.
E.g. EAR contains foo.jar and bar.jar, then:
CF.deploy(foo.jar)
CF.deploy(bar.jar)
CF.init(foo.jar)
CF.init(bar.jar)
CF.start(foo.jar)
CF.start(bar.jar)
That is the only way to make this work with larger applications. Having
deploy do init/start as well as is done today is no good really.
> This simple refactoring would, I believe, solve my problem; however, it's
> entirely possible there's something I've missed and/or someone's already
> working on this. Since some of my colleagues require this behavior
> immediately, I'm going to start work on it, but any
> comments/suggestions/tirades would be appreciated,
See above. It's a needed change. Basically refactory out init/start from
deploy(). But you need to be able to pass a nice metadata model around
as well (in order to resolve links) so that'll have to wait a bit.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
