Hi!
"Jung , Dr. Christoph" wrote:
> I would like to propose a refactoring of the ContainerFactory (i.e., the
> HUUUUUUGE deploy(URL url) blob) that
> IMHO allows for an easier integration of variuous deployment services where
> class and hence classloader identity is important (e.g., EmbeddedTomcat?).
>
> Background: We at infor are about to build a complex ERP not as a single EJB
> application, but as a modular conglomerate of interacting EJB applications
> (such as sales.jar, procurement.jar, stock.jar, masterdata.jar, etc.). For
> that purpose, we use an extension to the EJB component model that allows to
> specify dependencies between ejb-jars (similar to the class-path entry in
> the jar manifest). Deploying a jar (e.g., a sales.jar) means to
> automatically deploy the prerequisite jars (e.g., masterdata.jar) in a
> superordinate classloader and means to automatically deploy further
> non-native-EJB meta-data (XML-databinding, OR-mapping) from the resulting
> classloader.
Sounds a lot like our J2EE-deployer.
> In order to build such an added-value "business component" deployer (similar
> to J2EEDeployer but with class and classloader identity being preserved)
We do that too..
> , we
> needed to extend the ContainerFactory with a deploy(URLClassloader loader)
> method that operates on an already constructed classloader. Unfortunately,
> this meant to copy&paste the whole deploy(URL url) logic (with numerous
> applications of encapsulation breaking to circumpass protection).
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.
> 1) a deploy(URL) exposed via JMX which just constructs the
> classloader and then calls 2)
> 2) a core deploy(URLClassloader loader) which does all the real
> stuff, also exposed via JMX
As above, not necessary.
> 3) individual
> deployStatelessSessionBean(BeanMetaData,Configuration),
> deployStatefulSessionBean(...)
> methods that build the containers, invokers and interceptors for
> the individual beans and are
> called selectively by 2)
> 4) a deployBean(BeanMetaData,Configuration) which collects all the
> common deployment code for
> all types of beans in 3)
> 5) real factory methods for configuration-independent objects such
> as createStatelessContainer(), createStatefulContainer(), invoked by 3)
>
> would
>
> a) increase readability of the code
> b) allow for a high reusability of the ContainerFactory
I can agree with a). Convince me of b).
> and c) enable the chaining of deployment services (e.g.,
> EmbeddedTomcat->jBoss Deployer)
> using the same URLClassLoaders ...
As above, we already do that today with the J2EEDeployer.
> Somebody else sharing this opinion (especially of Rickard, Marc, Juha,
> Sebastien) and thinking that this idea is of some value?
Refactoring is ok, but not for the above stated reason.
> BTW: I could not figure out completely how the EmbeddedTomcatService shares
> classes with the container for optimizing JRMP calls ... maybe I�m fully
> wrong with the requirement of classloader identity?
Yup. See J2EEDeployer which creates a parent classloader to both Tomcat
and JBoss EJB. Very very clean.
> I know that this is at the heart of the container and not of my business to
> change. So, if my idea is not too far off, I would volunteer to do the
> refactoring locally and post the diffs for discussion ...
I'm ok with splitting up deploy(), but only for readability. The other
reasons are (AFAICT) non-issues.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
