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
