You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Steve Short <ss...@postx.com> on 2002/09/24 00:58:34 UTC
[PATCH] Replace Component Classes with Service Equivalents
Following my email a few days ago - here is a patch to replace Component
Classes with Service Equivalents in Cornerstone Store, RepositoryManager
and AbstractFileRepository. Diff generated using cvs diff -u at top
level jakarta-avalon-cornerstone directory.
Regards
Steve
<<cornerstone.diff>>
Re: [PATCH] Replace Component Classes with Service Equivalents
Posted by Berin Loritsch <bl...@apache.org>.
Peter M. Goldstein wrote:
> Berin,
>
>
>>Please note that the Container package now contains a Legacy
>
> subpackage
>
>>which you can use to wrap any ServiceManager with a
>>LegacyComponentManager. The LegacyComponentManager ensures that all
>>components are accessible by generating a Proxy object that implements
>>the role interface and the Component interface. You can even expose
>>a ServiceManager when the parent only has a ComponentManager. There
>>are testcases to verify it works. The ECM was retrofitted with it
>>because someone removed the Component interface from Monitor
>>implementations. It works well.
>
>
> Sounds like a godsend. Where is it? I looked in Avalon-framework
> src/java/org/apache/Avalon/framework/container and saw no subpackage.
> Am I misinterpreting?
It's in Excalibur's Container package:
${jakarta-avalon-excalibur}/container/src/org/apache/excalibur/container/legacy/*
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Replace Component Classes with Service Equivalents
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Berin,
> Please note that the Container package now contains a Legacy
subpackage
> which you can use to wrap any ServiceManager with a
> LegacyComponentManager. The LegacyComponentManager ensures that all
> components are accessible by generating a Proxy object that implements
> the role interface and the Component interface. You can even expose
> a ServiceManager when the parent only has a ComponentManager. There
> are testcases to verify it works. The ECM was retrofitted with it
> because someone removed the Component interface from Monitor
> implementations. It works well.
Sounds like a godsend. Where is it? I looked in Avalon-framework
src/java/org/apache/Avalon/framework/container and saw no subpackage.
Am I misinterpreting?
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Replace Component Classes with Service Equivalents
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> Following lots of discussion with regard to this change on james-dev
> currently going on, I feel I need to -1 this change until at least the
> next major release for Cornerstone (ie until 5.0), as it breaks backward
> compatibility.
>
> Rationale
> ---------
> Some projects (ie JAMES) expose the ComponentManager interface, and
> hence the Component interface, as part of their API, while also
> depending on some of the cornerstone components and exposing these
> through the ComponentManager by contract. Hence, removing Component and
> ComponentManager from Cornerstone means that this client API breaks.
>
> We should be supportive of our fellow developers at JAMES -- and any
> other projects with a similar concern -- and give them the time to
> handle this issue gracefully.
>
> We should, however, formally deprecate the pieces in Cornerstone that
> depend on the Component (& friends) interfaces, and indicate that they
> will move to ServiceManager in the future, if we still want to continue
> with this change.
>
>
> Impact
> ------
> This means that containers that want to be able to host the Cornerstone
> components (ie Phoenix, Merlin) need to keep supporting
> Component/Composable and friends. This is a good thing =)
Please note that the Container package now contains a Legacy subpackage
which you can use to wrap any ServiceManager with a
LegacyComponentManager. The LegacyComponentManager ensures that all
components are accessible by generating a Proxy object that implements
the role interface and the Component interface. You can even expose
a ServiceManager when the parent only has a ComponentManager. There
are testcases to verify it works. The ECM was retrofitted with it
because someone removed the Component interface from Monitor
implementations. It works well.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Replace Component Classes with Service Equivalents
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Seems like a sensible reason.
Is Cornerstone near a new minor release, or does it make sense to branch
and
apply the patch to the new branch?
Off Topic: Anyone been able to access www.apache.org today?
/LS
> From: Leo Simons [mailto:leosimons@apache.org]
>
> Following lots of discussion with regard to this change on
> james-dev currently going on, I feel I need to -1 this change
> until at least the next major release for Cornerstone (ie
> until 5.0), as it breaks backward compatibility.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Replace Component Classes with Service Equivalents
Posted by Leo Simons <le...@apache.org>.
Following lots of discussion with regard to this change on james-dev
currently going on, I feel I need to -1 this change until at least the
next major release for Cornerstone (ie until 5.0), as it breaks backward
compatibility.
Rationale
---------
Some projects (ie JAMES) expose the ComponentManager interface, and
hence the Component interface, as part of their API, while also
depending on some of the cornerstone components and exposing these
through the ComponentManager by contract. Hence, removing Component and
ComponentManager from Cornerstone means that this client API breaks.
We should be supportive of our fellow developers at JAMES -- and any
other projects with a similar concern -- and give them the time to
handle this issue gracefully.
We should, however, formally deprecate the pieces in Cornerstone that
depend on the Component (& friends) interfaces, and indicate that they
will move to ServiceManager in the future, if we still want to continue
with this change.
Impact
------
This means that containers that want to be able to host the Cornerstone
components (ie Phoenix, Merlin) need to keep supporting
Component/Composable and friends. This is a good thing =)
best regards,
Leo Simons
On Tue, 2002-09-24 at 14:21, Peter Donald wrote:
> Applied - thanks!
>
> On Tue, 24 Sep 2002 08:58, Steve Short wrote:
> > Following my email a few days ago - here is a patch to replace Component
> > Classes with Service Equivalents in Cornerstone Store, RepositoryManager
> > and AbstractFileRepository. Diff generated using cvs diff -u at top
> > level jakarta-avalon-cornerstone directory.
> >
> > Regards
> > Steve
> >
> > <<cornerstone.diff>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Replace Component Classes with Service Equivalents
Posted by Leo Simons <le...@apache.org>.
Following lots of discussion with regard to this change on james-dev
currently going on, I feel I need to -1 this change until at least the
next major release for Cornerstone (ie until 5.0), as it breaks backward
compatibility.
Rationale
---------
Some projects (ie JAMES) expose the ComponentManager interface, and
hence the Component interface, as part of their API, while also
depending on some of the cornerstone components and exposing these
through the ComponentManager by contract. Hence, removing Component and
ComponentManager from Cornerstone means that this client API breaks.
We should be supportive of our fellow developers at JAMES -- and any
other projects with a similar concern -- and give them the time to
handle this issue gracefully.
We should, however, formally deprecate the pieces in Cornerstone that
depend on the Component (& friends) interfaces, and indicate that they
will move to ServiceManager in the future, if we still want to continue
with this change.
Impact
------
This means that containers that want to be able to host the Cornerstone
components (ie Phoenix, Merlin) need to keep supporting
Component/Composable and friends. This is a good thing =)
best regards,
Leo Simons
On Tue, 2002-09-24 at 14:21, Peter Donald wrote:
> Applied - thanks!
>
> On Tue, 24 Sep 2002 08:58, Steve Short wrote:
> > Following my email a few days ago - here is a patch to replace Component
> > Classes with Service Equivalents in Cornerstone Store, RepositoryManager
> > and AbstractFileRepository. Diff generated using cvs diff -u at top
> > level jakarta-avalon-cornerstone directory.
> >
> > Regards
> > Steve
> >
> > <<cornerstone.diff>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Replace Component Classes with Service Equivalents
Posted by Peter Donald <pe...@apache.org>.
Applied - thanks!
On Tue, 24 Sep 2002 08:58, Steve Short wrote:
> Following my email a few days ago - here is a patch to replace Component
> Classes with Service Equivalents in Cornerstone Store, RepositoryManager
> and AbstractFileRepository. Diff generated using cvs diff -u at top
> level jakarta-avalon-cornerstone directory.
>
> Regards
> Steve
>
> <<cornerstone.diff>>
--
Cheers,
Peter Donald
Duct tape is like the force. It has a light side, and a dark side, and
it binds the universe together ...
-- Carl Zwanzig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>