cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <>
Subject RE: [heads-up] The version of ECM in CVS has a change in JDK reqs
Date Sat, 28 Sep 2002 13:26:53 GMT

> From: Berin Loritsch [] 
> One of the fundamental issues with the move from 
> ComponentManager to ServiceManager is what do we do with 
> components that do not implement the "Component" interface.  
> This is especially important because someone removed the 
> Component interface from the Monitor components in Excalibur 
> CVS.  The solution, believe it or not was already written, 
> but ECM didn't take advantage of it.
> ECM now uses a sporty new utility called a 
> ComponentProxyGenerator, which requires JDK 1.3 or higher 
> because it generates a Proxy for the component that extends 
> the component's role interface and the Component interface.  
> As a result you can use the ComponentManager to access legacy 
> systems where you don't have access or privelege to change 
> the interface.  In the end this change is for the better.
> As a result, if Cocoon wants to use the latest and greatest 
> ECM, then it must use JDK 1.3 or higher.  I am sure that JDK 
> 1.3 will help make some things easier to do in Cocoon.  Also 
> note that should Cocoon use the latest and greatest from 
> Fortress (comming to a store near you RSN) or Merlin, it 
> would have to upgrade to JDK 1.3 or better anyway.

While I'm sure the change is for the better, if anyone has
deployed Cocoon an a JDK1.2.2 system, this effectively makes
them out of luck when it comes to Cocoon bugfixes etc.

Cocoon 2.0 has been out for a year, and I think it is a severe
violation of contracts to suddely say that "sorry, you need
JDK 1.3" when Cocoon so far has maintained JDK1.2 compatibility.


    Apache Cocoon requires the following systems to be already 
    installed in your system: 

    Java Virtual Machine A Java 1.2 or later compatible virtual 
    machine must be present for both command line and servlet 
    type usage of Apache Cocoon. Note that all servlet engines 
    require a JVM to run so if you are already using servlets you 
    already have one installed. 

I bet people have made business decisions based on that information.

Somehow this contract must be maintained, at the very least for 
the 2.0 branch.

 + Avalon 4 contains the ComponentManager interface and thus 
   *all* component that claim to be Avalon 4 compatible MUST
   support the Component interface. Yes, it is deprecated, but
   unless you intend to roll out A5, Component et al. are there
   to stay and *must* be supported. Solution: Let Monitor implement 
   Component again. That would make it A4 compliant. Then there's
   no need for the proxy generator for Cocoon.

 + Maintain 2 versions of ECM - one 1.2 without the proxy and one 1.3+
   with it.

Finally, Avalon makes ***no*** promises that I could find on the 
webpages about what JDK it will run / compile on. So I think the 
promise made by the Cocoon team of supporting JDK1.2 is a bit 
impossible, and that it should be qualified to be for the 2.0 branch 
only or something.

(Avalon team: Do we promise anything in regard to JVM versions?)


To unsubscribe, e-mail:
For additional commands, email:

View raw message