hey,
need to go but read your mail and rickard's responses. Rickard has points
christoph... will get back to it.
Can you give a precise example of what you call "non-flat" deployment, with
the javabeans in it etc etc. See the JBoss containerFactory is a
EJBContainerFactory, that being said we need a ApplicationContainerFactory
and the current Deployer is a catastrophy. So please give us something to
work from.
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Jung , Dr.
|Christoph
|Sent: Wednesday, December 06, 2000 6:29 AM
|To: 'jBoss Developer'
|Subject: AW: [jBoss-Dev] Proposed refactoring of ContainerFactory -
|Chain ingDeployment se rvices in general
|
|
|Hi Rickard,
|
|thanks for your comments which now let me see some things clearer and
|hopefully
|helped to restate my arguments as follows ...
|
|-----Urspr�ngliche Nachricht-----
|>Von: Rickard �berg [mailto:[EMAIL PROTECTED]]
|>Gesendet: Mittwoch, 6. Dezember 2000 13:49
|>An: jBoss Developer
|>Betreff: Re: [jBoss-Dev] Proposed refactoring of ContainerFactory -
|>ChainingDeployment se rvices in general
|
|>Sounds a lot like our J2EE-deployer.
|
|Yes, I love to paste our additional deployment services into the
|J2EE-deployer.
|
|>This is not necessary. It works with the current ContainerFactory. All
|>you have to do in your deployer (and which the J2EEDeployer does) is set
|>the parent classloader as thread context classloader. If you look in
|>deploy() it will be picked up as parent to the EJB classloader, hence
|>keeping things coherent.
|
|Now I see, but somehow don�t like it:
|
|- Its a rather implicit mechanism, isn�t it? Relies on the fact that each
|deployer/service depending on class/classloader identity knows
|that the leaf
|loaders are indeed redundant and checks for the parent for
|comparison ... hmmm ... at least not what I would have implemented (or
|expected any other RMI/ORB-implementations to have employed) as the default
|optimisation check.
|
|- Is IMHO not so clean and explicit as having the services
|communicating the
|classloader
|explicitely via an additional deploy(ClassLoader, URL) method ...
|
|- Makes it impossible to extend (i.e., build non-faked childs of) the leaf
|classloaders coherently among several services on the fly (see my
|idea about
|a big, modular system comprised out of individual, but interdependent
|ejb-applications).
|
|>I can agree with a). Convince me of b).
|
|In the end, you�ve cut down my arguments into two:
|
|a) makes the ContainerFactory (maybe afterwards the J2EEDeployer,
|EmbeddedTomcat) code more readable
|
|b) allows for a reusability of J2EEDeployer, ContainerFactory and
|EmbeddedTomcat also when having
|"non-flat" deployment structures.
|
|Maybe b) is just a non-standard infor issue (we are not using Entity Beans
|as data sources, but rather persistable and serializable
|Java-Beans that are
|communicated through Session Beans and hence are also deployed within the
|ejb-jars) ?
|
|> I'm ok with splitting up deploy(), but only for readability. The other
|>reasons are (AFAICT) non-issues.
|
|Best,
|CGJ
|
|
