cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [SUMMARY] From Woody to Cocoon Forms 1.0
Date Fri, 05 Mar 2004 21:10:24 GMT
Tim Larson wrote:

> On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote:

>>  Package: org.apache.cocoon.cforms
>>here I would go "forms" instead. package naming is where the estate 
>>really is, where class collissions might happen.
> I understand how this seems like a good place for the battleground,
> but to introduce a new winner it looks like this would force us to
> break code compiled against the previous major version because we
> would be stealing the class and interface names for the new version.
> Does the new block system somehow solve this problem like via
> classloaders or something else?

eh, very good question, actually. I spent a few hours discussing with 
Pier about this yesterday over IM. Pier, as usual, sees the very core 
problem and I always miss ;-)

The way the JVM classloading mechanism is designed (well, the code 
verifier actually) is that you cannot have two classes with the same 
name and package in the same classloading hierarchy.

So, for example, suppose you have the following hierarchy:


where block A depends on block B and C. Now, if B and C expose the same 
class, there is no problem if that is accessed from B or from C 
internally, but as soon as A starts to access it, which one does it get?

So, in short, it is feasible (IMHO, even if I haven't tried yet) to come 
up with a classloading hierarchy that allows isolation, but only when 
the semantics associated to the class usage are *really* isolated.

Note that this seems easy to enforce, but it's really not, especially if 
you get into block versioning!!!

   A   D
    \ / \
     C   E
      \   \
       F   X.2

Now, if A asks for a particular task that B executes, requiring version 
1 of block X, then asks for another task, executed by C, left to D, 
which handles to E which requires version 2 of X, then you get a 
ClassCastException. No way out!

And debugging this is going to be the biggest pain in the universe!!

So, my suggestion is to create a dependency checker which will tell all 
the potential class collision conflicts, at deploy time (by crawling the 
class space, perform MD5 hashing of classes and identify collisions)

So, in short: having to different versions of the same interface in 
memory is possible only if there is always a way for the system to 
differentiate between them. that is: no way to use them both.

Trivial for a few blocks, but very tricky when the number of blocks 
dependencies explodes.

This is the best answer I can give at the moment.

Pier, anything to add here?


View raw message