Hi there,
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.
In order to build such an added-value "business component" deployer (similar
to J2EEDeployer but with class and classloader identity being preserved), 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).
At this point, it strikes me that a refactoring of the deploy(URL url)
method into
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
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
and c) enable the chaining of deployment services (e.g.,
EmbeddedTomcat->jBoss Deployer)
using the same URLClassLoaders ...
Somebody else sharing this opinion (especially of Rickard, Marc, Juha,
Sebastien) and thinking that this idea is of some value?
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?
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 ...
Best,
CGJ
