cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Java components in blocks
Date Wed, 13 Apr 2005 11:40:57 GMT
Pier Fumagalli wrote:

> Ok, here is where I don't agree...
> By adding to blocks the capability of "bringing components" with them, 
> we enter a quite big minefield, imposed by the restrictions of the Java 
> VM. The complexity escalates at this point as now blocks must be aware 
> of their class-loading mechanism, and the component manager must be 
> aware of blocks and interfaces.
> For example, classes and libraries included in an interface block must 
> be loaded by the parent ClassLoader of the blocks using (implementing, 
> extending, requiring) them to avoid ClassCastException(s).
> So, alongside blocks and their deployment graph (block A extends B, 
> implements C, ... blabla ...) we need to start keep tracking also the 
> classes included in those blocks, and create a completely different tree 
> based on the class loading structure that those represent.
> And then you get into the minefield of versioning... If it's easy to 
> determine that two versions of the same block can co-exist (by using two 
> separate class loaders children of the same parent) without creating too 
> many problems, what happens in the case of two interfaces with different 
> versions? The class loading tree should (at this point) become very 
> fine-grained and start building multiple class-loaders for multiple 
> versions of the same interface, and then build as children of those 
> class loaders for the individual blocks "using" them, ...

Hmmm, are we really the first project tackling this? How did Eclipse solved this?

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


View raw message