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}web(log): http://www.poetz.cc --------------------------------------------------------------------
