You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/09/27 22:54:48 UTC
[heads-up] The version of ECM in CVS has a change in JDK reqs
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.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [heads-up] The version of ECM in CVS has a change in JDK reqs
Posted by Leo Simons <le...@apache.org>.
On Sat, 2002-09-28 at 15:26, Leo Sutic wrote:
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
<snip>
> > 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.
-1 on defining "avalon compatible component" this way. The whole point
of service.* is that you can have "avalon compatible components" that do
not implement Component!
> Yes, it is deprecated, but
> unless you intend to roll out A5, Component et al. are there
> to stay and *must* be supported.
my personal stance is that avalon framework, the avalon containers etc
should support Component & friends. I however don't feel that all avalon
components must do the same (it can be made a container concern to
handle the pain, it has been made a container concern, and I like
that...)
That said, I can't really see why it would be a problem to have all
components the ECM depends on extend Component.
> Solution: Let Monitor implement
> Component again. That would make it A4 compliant. Then there's
> no need for the proxy generator for Cocoon.
if at all possible I would like to see a solution where the container
handles the 'legacy support'. I am not any kind of bytecode/rmi wizard
though so I am not sure that is feasible.
I have no problem at all with Monitor implementing Component though.
> + Maintain 2 versions of ECM - one 1.2 without the proxy and one 1.3+
> with it.
ieeuw! If that's what it takes, that's what it takes though.
> 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.
seems like it. I sure never test against 1.2.
However, a promise made is a promise made and if it is relatively easy
(IIUC all we need to do is implement Component for the various
components in excalibur CVS) for us to help Cocoon keep that promise I'm
all for it. Especially since the alternative (code fork) sounds like it
will be painful.
> (Avalon team: Do we promise anything in regard to JVM versions?)
generally, I (and others) complain very loudly when some stuff stops
working on 1.3. Other people do the same for 1.4. We have no formal
rules/promises across-project, and I think it should stay that way.
(There can be good reasons for hosting a jdk1.4-only component in avalon
cvs, or even (especially) a jdk1.5-only).
I do feel it would be good to clearly specify supported JVM versions for
different (sub)subprojects.
Just some opinions =)
cheers,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [heads-up] The version of ECM in CVS has a change in JDK reqs
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [heads-up] The version of ECM in CVS has a change in JDK reqs
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org