> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> 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.
See http://xml.apache.org/cocoon/installing/index.html:
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?)
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
