Hi!
"Jung , Dr. Christoph" wrote:
> >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.
True, but since we cannot change Tomcat it was the best/easiest way to
do it.
> - Is IMHO not so clean and explicit as having the services communicating the
> classloader
> explicitely via an additional deploy(ClassLoader, URL) method ...
True, see above.
> - 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).
Don't understand. Expand please. Example would help.
> >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
Yes. Agree.
> b) allows for a reusability of J2EEDeployer, ContainerFactory and
> EmbeddedTomcat also when having
> "non-flat" deployment structures.
Again, don't follow. What do you mean by this?
> 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) ?
Yes, and the problem is..?
regards,
Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
