Re: [SUMMARY] From Woody to Cocoon Forms 1.0

[Stefano Mazzocchi]

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:

    B
   /
  A
   \
    C

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!!!

      X.1
     /
    B
   /
  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?

--
Stefano.

smime.p7s

Description: S/MIME Cryptographic Signature