"Jung , Dr. Christoph" wrote:
> What we have implemented using a heavily modified ContainerFactory (and what
> I think could be of interest for the jBoss community, too, if more elegantly
> integrated into J2EEDeployer)
> is that such jars with dependencies (here, sales-->masterdata<--stock) can
> be deployed in a manner that if sales is deployed, masterdata is
> automatically deployed in a parent classloader of sales (recursive
> deploy(URL) call delivers ClassLoader back which will be used as the parent
> classloader). If stock is deployed and masterdata is already up (@see
> ContainerFactory.deployedComponents), it just uses the existing classloader
> as parent. If masterdata is redeployed, running stock and sales applications
> are automatically cycled, too. The implementation goes actually a bit
> further by also allowing cyclic dependencies where a clique of jars is
> deployed into the same classloader ... The result is in each case a
> hierarchy of classloaders that is extensible at runtime (therefore I talked
> about non-flat deployment).
So far I cannot see any difference between what you describe and having
J2EE applications (.ear files) with multiple JAR files. What am I
missing?
> In principle, all the business services can now interact: (XML-)
> serialisation is applied to transfer sales representations into stock
> representations (e.g., the ProcessOrder.processOrder(PurchaseOrder) method
> calls the WarehouseService.reserveItems(Item,int) method). Optimised direct
> calls can be used as you travel along the dependencies, i.e., the
> hierarchical Classloader structure (e.g., the processOrder() calls
> DocumentAdministrator.copyDocument(Document)).
Are you saying that you are having multiple EAR applications, and where
an EAR can optionally specify it's parent EAR? The biggest reason seems
to be to allow classloader sharing, which is only relevant for call
optimization (no serialization needed). Is that a correct understanding
of what you're saying?
> So, it�s simply not possibly to compile the whole stuff once at installation
> time into a single jar especially for hot-maintenance, hot-updates, and
> hot-configuration.
But multiple EAR's would do the trick, right?
> It�s also impracticable to build completely independent
> jars (just sales and stock each containing the masterdata functions) because
> of redundancy and consistency purposes.
But what if sales and stock both references masterdata *jar*'s through
classpath manifest? I.e. they are seemingly redundant but in reality use
the same jar. Would that be ok?
> I hope you could follow my thoughts, I hope that not all of this has been
> already possible the whole time, and hence my question: Is such a deployment
> behaviour of general interest such that I should post the extended
> J2EEDeployer once ready?
If I understand you correctly, all you're saying is that you want an EAR
to be able to specify a "parent", and then that parents classloader
should be used as parent to the EAR's own classloader. Right? That
sounds ok, but with the above note that it is only really useful for
call optimization. Or are there more benefits?
Nevertheless, yes this is interesting :-)
regards,
Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
