You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@osm.net> on 2002/02/09 01:53:41 UTC
ComponentManager interface
Given that Component's existence is under considered of being
depreciated, can anyone provide some hints as to probability
and timeframe of the ComponentManager.lookup operation returning
Object instead of Component. The reason I'm asking is that such
a change would be very beneficial to the things I'm working on
that do not and will never implement Component
(e.g. org.omg.CORBA.Object).
Cheers, Steve.
Stephen J. McConnell, OSM sarl
digital products for a global economy
http://www.osm.net
mailto:mcconnell@osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager interface
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
> So maybe we just create something that is a stop-gap till
>Framework 5.0 ?
>
paul.setMood(Mood.OVERTHEMOON);
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
On Mon, 11 Feb 2002 00:25, Paul Hammant wrote:
> Peter,
>
> >>Composable2, ComponentManager2 ?
> >
> >ewww - runaway, runaway ;)
>
> I knew we we going round in circles dude.... You're the one pushing
> for 'Component becomes Object' (by implication) then backing away ;-)
Im not backin away. I think backwads compatability is important as is
conceptual clarity.
> I don't like Stephens new ServiceXXXX stuff. I mean it is good. No it
> is perfect but for the absense of the word "Component".
I actually prefer it because it clears up the confusion associated with word
Component. Though it does add the Service terminology confusion ;)
ComponentManager is basically a service directory - you look up services via
a search string (which happens to match their interface usually).
> We are not without precident, all these from JDK1.4 :
>
> LayoutManager2
> GlyphPainter2
> Parser2 (Crimson)
> ElementNode2
> NamespaceSupport2
If Sun jumped off a cliff would you do it too ? ;)
--
Cheers,
Pete
-------------------------------------------------------
To fight and conquer in all your battles is not supreme
excellence; supreme excellence consists in breaking the
enemy's resistance without fighting. - Sun Tzu, 300 B.C.
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
James:
James Pepe wrote:
> First off, I'd like to say hello to everyone, as I am new to this
> list, and new to the Avalon project so forgive me if I make any undue
> assumptions. I love the work so far, and am here to (hopefully) make
> some worthwhile contributions, and get a jump on the upcoming releases.
Welcome to Avalon!
> To solve the "Object" problem ... Why not add an "ObjectManager"
> interface that uses the "resolve()" idea from earlier? Whereas the
> new RI class would be called ExcaliburObjectManager and extend
> ExcaliburComponentManager implementing the ObjectManager interface.
>
> e.g.:
> ExcaliburObjectManager manager;
> /* horrendous code here */
> Object o = manager.resolve(thisObject);
> Component c = manager.lookup(thisComponentPleaseKindSir);
>
> Not sure what its implications are to the project. Thoughts?
To do this you need to handle different treatment for operations such
as hasComponent (only returns true if the manger has a object and the
object is an instance of Component). In the above example you could
get the same object returned from both resolve and lookup (because the
objet registered with the manager implements Component). This gets
messy in the implementation of DefaultComponentManger when dealing with
non-null parent ComponentManagers. This is part of what I was
referring to my earlier email to Paul and the reference to Ministrone!
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager interface
Posted by James Pepe <jp...@typhoon.lightning.net>.
First off, I'd like to say hello to everyone, as I am new to this list, and
new to the Avalon project so forgive me if I make any undue assumptions. I
love the work so far, and am here to (hopefully) make some worthwhile
contributions, and get a jump on the upcoming releases.
With that aside ....
To solve the "Object" problem ... Why not add an "ObjectManager" interface
that uses the "resolve()" idea from earlier? Whereas the new RI class would
be called ExcaliburObjectManager and extend ExcaliburComponentManager
implementing the ObjectManager interface.
e.g.:
ExcaliburObjectManager manager;
/* horrendous code here */
Object o = manager.resolve(thisObject);
Component c = manager.lookup(thisComponentPleaseKindSir);
Not sure what its implications are to the project. Thoughts?
Best,
Jim Pepe
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager interface
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
Dude, I was not trying to be offensive... Your proposal was not
half-baked, it was well thought out.
- Paul
>Paul:
>
>I guess I'm looking at this from a completely different point
>of view. After coming up with my half-backed proposal for
>changes to ComponentManager (I shouldn't make proposals after
>being awake that long), I was rightfully shot down on the issue
>of backwards compatibility. Now its clear that the
>compatibility question is technical debatable - after all,
>if anyone really using a returned value of component as Component?
>Bottom line - its contractual - and you don't break contracts
>(forget about the technical issues .. its marketing principal
>we need to worry about). So option (1) isn't an option. We
>have option (2) and option (3). Before Pete sent his suggestion
>I had been playing around with variants - one approach was to
>come up with a specialisation of ComponentManager but that just
>turned into Minestrone soup (specialising a class to add what
>in principal should be super-type behaviour). I tried a couple
>of variants of this but constantly ran foul of the fact that
>DefaultComponentManager has a parent ComponentManager which
>implies lots if [if instanceof Component do X else do Y] stuff.
>My conclusion from that was to drop the idea of Band-Aid
>treatment (a) because it just didn't hang together, and (b)
>Avalon is fundamentally very clean in the Band-Aid principal was
>ranking very high on the "suck" scale. Next step was to address
>extension (ComponentManager2 or a other name in the same package)
>or a new package. I tried coming up with new package
>names but frankly could not think of anything with the equivalent
>elegance of the current framework packages - furthermore, I really
>struggle trying to come up with some more meaningful class names
>assuming continuation under the component package. Put it down
>to insufficient IQ - I didn't arrive at anything interesting and
>that bugged me most on marketing grounds.
>
>Five minutes later Pete posted his suggestions, one of which I
>jumped on immediately - the framework/service package (with
>adjustment to correct the spelling to Serviceable :-)).
>
>Here is why I jumped ...
>
> (1) because it grammatically made perfect sense in the context
> of the overall framework
> (2) because I can market those terms without compromising
> anything on the component model - in fact enhancing it
> (see point 3)
> (3) because I can leverage the fact that the Avalon
> component model now encompasses legacy applications
> (evidence of which is already implemented and tested)
>
>And most importantly for me ...
>
> (4) because I'm busy recruiting new Avalon advocates from
> a legacy (CORBA) community (that are reading these
> messages) and I need a clean story backed by a relevant
> set of interfaces and implementations (which we now have
> pending general agreement - example org.apache.orb.ORB
> can now be supplied by a manager to the components it
> manages while maintaining 100% CORBA spec compliance and
> incorporating the Avalon component model for logging,
> configuration, and contextualization).
>
>Summary .. this isn't ComponentManager2!
>The new package quite elegantly reflects the computation interfaces
>needed by a "component" in the declaration of the contracts
>concerning the service provision and service disposal aspect.
>
>Cheers, Steve.
>
>
>>-----Original Message-----
>>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>>Sent: Sunday, 10 February, 2002 17:18
>>To: Avalon Developers List
>>Subject: Re: ComponentManager interface
>>
>>
>>Stephen,
>>
>>I'm not so sure. We're trying to sell Component assembly, component
>>orientated programming. With the proposal with Service as the
>>replacement word, we've duplicated an entire package. I thought
>>wholescale class cloning was no-no, even at tool level.
>>
>>We have three choices:
>>
>>1) Brave replacement of Component with Object return type on lookup(..).
>>
>> Pros: small change
>> Cons: Not backwards compatible - lots of recompilation and possible
>>casting needed for users of API
>>
>>2) Package clone (as per proposal booked in).
>>
>> Pros: backwards compatible.
>> Cons: Overkill duplication, confusion.
>>
>>3) "2" suffixed interfaces
>>
>> Pros: new new package, backwards compatible. Smaller amount
>>of changes.
>> Cons: "ugly" digit suffix to interface names.
>>
>>I think (3) is a front runner. For (2) the "medicine is worse than the
>>cure". (1) I would do for selfish reasons, but we'd upset various
>>communities, possibly to the point of mutiny.
>>
>>However, I am not active in maint of framework. I will leave the
>>decision to others, but state that my highest concern is a timeline. I
>>will vote..... if (1) is vetoed I'll vote for (3) over (2) and I really
>>believe that loading a gun and shooting a package to avoid a "2" suffix
>>is over the top.
>>
>>- Paul
>>
>>
>>
>>>Paul:
>>>
>>>I don't agree with point concerning the absence of the
>>>word "Component" - a component is an abstract thing - more
>>>abstract than the computational descriptions we can put
>>>into Java interfaces. In fact I think the absence of the
>>>word component in the interface name clarifies (for me) the
>>>function from a computational perspective as distinct from
>>>the role of the interface in the overall component
>>>abstraction.
>>>
>>>Its Sunday afternoon and there are just too many big word
>>>in that paragraph - time I had another glass of wine!
>>>
>>>Cheers, Steve.
>>>
>>>
>>>>-----Original Message-----
>>>>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>>>>Sent: Sunday, 10 February, 2002 14:25
>>>>To: Avalon Developers List
>>>>Subject: Re: ComponentManager interface
>>>>
>>>>
>>>>Peter,
>>>>
>>>>>>Composable2, ComponentManager2 ?
>>>>>>
>>>>>ewww - runaway, runaway ;)
>>>>>
>>>>I knew we we going round in circles dude.... You're the one pushing
>>>>for 'Component becomes Object' (by implication) then backing away ;-)
>>>>
>>>>I don't like Stephens new ServiceXXXX stuff. I mean it is good. No it
>>>>is perfect but for the absense of the word "Component".
>>>>
>>>>We are not without precident, all these from JDK1.4 :
>>>>
>>>> LayoutManager2
>>>> GlyphPainter2
>>>> Parser2 (Crimson)
>>>> ElementNode2
>>>> NamespaceSupport2
>>>>
>>>><fx> ducks from Peter's bullets </fx>
>>>>
>>>>Packages Evolve. Lets understand that. We have no versioning built
>>>>into Java in the sense that two versions of the same API could
>>>>interoperate in the same classloader/classpath. In ten years time we
>>>>will have loads of dead packages (java.io is example) or loads of
>>>>suffixed classes/interfaces. We could migrate all functionality
>>>>immediately to the "2" versions and for the original versions have a
>>>>hand crafted proxy that routes all calls through to the new one.
>>>>
>>>>It is one strategy that will be taken with AWT in the end I guess.
>>>>Sun/Netacape built Swing on top of the AWT primatives, but kept AWTs
>>>>own heavyweight comps. Sun could obsolete AWT and or have a near enough
>>>>pure Java "AWT2" that AWT routes through to. In fact AWT could route
>>>>through to Swing, more or less completely hiding the experience. In
>>>>that version of the graphic toolkit all Swing would need from the
>>>>iunderlying OS would be mouse, kbd and "rectangle reservation" graphics
>>>>support. Swing could sit small OSs that have no advanced graphics API.
>>>>Sigh... Java's original Component model ;-)
>>>>
>>>>- Paul
>>>>
>>>>
>>>>
>>>>--
>>>>To unsubscribe, e-mail:
>>>>
>>><ma...@jakarta.apache.org>
>>>For additional commands, e-mail:
>>>
><ma...@jakarta.apache.org>
>
>>
>>--
>>To unsubscribe, e-mail:
>>
><ma...@jakarta.apache.org>
>
>>For additional commands, e-mail:
>>
><ma...@jakarta.apache.org>
>
>>
>>
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
Paul:
I guess I'm looking at this from a completely different point
of view. After coming up with my half-backed proposal for
changes to ComponentManager (I shouldn't make proposals after
being awake that long), I was rightfully shot down on the issue
of backwards compatibility. Now its clear that the
compatibility question is technical debatable - after all,
if anyone really using a returned value of component as Component?
Bottom line - its contractual - and you don't break contracts
(forget about the technical issues .. its marketing principal
we need to worry about). So option (1) isn't an option. We
have option (2) and option (3). Before Pete sent his suggestion
I had been playing around with variants - one approach was to
come up with a specialisation of ComponentManager but that just
turned into Minestrone soup (specialising a class to add what
in principal should be super-type behaviour). I tried a couple
of variants of this but constantly ran foul of the fact that
DefaultComponentManager has a parent ComponentManager which
implies lots if [if instanceof Component do X else do Y] stuff.
My conclusion from that was to drop the idea of Band-Aid
treatment (a) because it just didn't hang together, and (b)
Avalon is fundamentally very clean in the Band-Aid principal was
ranking very high on the "suck" scale. Next step was to address
extension (ComponentManager2 or a other name in the same package)
or a new package. I tried coming up with new package
names but frankly could not think of anything with the equivalent
elegance of the current framework packages - furthermore, I really
struggle trying to come up with some more meaningful class names
assuming continuation under the component package. Put it down
to insufficient IQ - I didn't arrive at anything interesting and
that bugged me most on marketing grounds.
Five minutes later Pete posted his suggestions, one of which I
jumped on immediately - the framework/service package (with
adjustment to correct the spelling to Serviceable :-)).
Here is why I jumped ...
(1) because it grammatically made perfect sense in the context
of the overall framework
(2) because I can market those terms without compromising
anything on the component model - in fact enhancing it
(see point 3)
(3) because I can leverage the fact that the Avalon
component model now encompasses legacy applications
(evidence of which is already implemented and tested)
And most importantly for me ...
(4) because I'm busy recruiting new Avalon advocates from
a legacy (CORBA) community (that are reading these
messages) and I need a clean story backed by a relevant
set of interfaces and implementations (which we now have
pending general agreement - example org.apache.orb.ORB
can now be supplied by a manager to the components it
manages while maintaining 100% CORBA spec compliance and
incorporating the Avalon component model for logging,
configuration, and contextualization).
Summary .. this isn't ComponentManager2!
The new package quite elegantly reflects the computation interfaces
needed by a "component" in the declaration of the contracts
concerning the service provision and service disposal aspect.
Cheers, Steve.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Sunday, 10 February, 2002 17:18
> To: Avalon Developers List
> Subject: Re: ComponentManager interface
>
>
> Stephen,
>
> I'm not so sure. We're trying to sell Component assembly, component
> orientated programming. With the proposal with Service as the
> replacement word, we've duplicated an entire package. I thought
> wholescale class cloning was no-no, even at tool level.
>
> We have three choices:
>
> 1) Brave replacement of Component with Object return type on lookup(..).
>
> Pros: small change
> Cons: Not backwards compatible - lots of recompilation and possible
> casting needed for users of API
>
> 2) Package clone (as per proposal booked in).
>
> Pros: backwards compatible.
> Cons: Overkill duplication, confusion.
>
> 3) "2" suffixed interfaces
>
> Pros: new new package, backwards compatible. Smaller amount
> of changes.
> Cons: "ugly" digit suffix to interface names.
>
> I think (3) is a front runner. For (2) the "medicine is worse than the
> cure". (1) I would do for selfish reasons, but we'd upset various
> communities, possibly to the point of mutiny.
>
> However, I am not active in maint of framework. I will leave the
> decision to others, but state that my highest concern is a timeline. I
> will vote..... if (1) is vetoed I'll vote for (3) over (2) and I really
> believe that loading a gun and shooting a package to avoid a "2" suffix
> is over the top.
>
> - Paul
>
>
>
> >Paul:
> >
> >I don't agree with point concerning the absence of the
> >word "Component" - a component is an abstract thing - more
> >abstract than the computational descriptions we can put
> >into Java interfaces. In fact I think the absence of the
> >word component in the interface name clarifies (for me) the
> >function from a computational perspective as distinct from
> >the role of the interface in the overall component
> >abstraction.
> >
> >Its Sunday afternoon and there are just too many big word
> >in that paragraph - time I had another glass of wine!
> >
> >Cheers, Steve.
> >
> >
> >>-----Original Message-----
> >>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> >>Sent: Sunday, 10 February, 2002 14:25
> >>To: Avalon Developers List
> >>Subject: Re: ComponentManager interface
> >>
> >>
> >>Peter,
> >>
> >>>>Composable2, ComponentManager2 ?
> >>>>
> >>>ewww - runaway, runaway ;)
> >>>
> >>I knew we we going round in circles dude.... You're the one pushing
> >>for 'Component becomes Object' (by implication) then backing away ;-)
> >>
> >>I don't like Stephens new ServiceXXXX stuff. I mean it is good. No it
> >>is perfect but for the absense of the word "Component".
> >>
> >>We are not without precident, all these from JDK1.4 :
> >>
> >> LayoutManager2
> >> GlyphPainter2
> >> Parser2 (Crimson)
> >> ElementNode2
> >> NamespaceSupport2
> >>
> >><fx> ducks from Peter's bullets </fx>
> >>
> >>Packages Evolve. Lets understand that. We have no versioning built
> >>into Java in the sense that two versions of the same API could
> >>interoperate in the same classloader/classpath. In ten years time we
> >>will have loads of dead packages (java.io is example) or loads of
> >>suffixed classes/interfaces. We could migrate all functionality
> >>immediately to the "2" versions and for the original versions have a
> >>hand crafted proxy that routes all calls through to the new one.
> >>
> >>It is one strategy that will be taken with AWT in the end I guess.
> >> Sun/Netacape built Swing on top of the AWT primatives, but kept AWTs
> >>own heavyweight comps. Sun could obsolete AWT and or have a near enough
> >>pure Java "AWT2" that AWT routes through to. In fact AWT could route
> >>through to Swing, more or less completely hiding the experience. In
> >>that version of the graphic toolkit all Swing would need from the
> >>iunderlying OS would be mouse, kbd and "rectangle reservation" graphics
> >>support. Swing could sit small OSs that have no advanced graphics API.
> >> Sigh... Java's original Component model ;-)
> >>
> >>- Paul
> >>
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:
> >>
> ><ma...@jakarta.apache.org>
> >For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
>For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager interface
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
I'm not so sure. We're trying to sell Component assembly, component
orientated programming. With the proposal with Service as the
replacement word, we've duplicated an entire package. I thought
wholescale class cloning was no-no, even at tool level.
We have three choices:
1) Brave replacement of Component with Object return type on lookup(..).
Pros: small change
Cons: Not backwards compatible - lots of recompilation and possible
casting needed for users of API
2) Package clone (as per proposal booked in).
Pros: backwards compatible.
Cons: Overkill duplication, confusion.
3) "2" suffixed interfaces
Pros: new new package, backwards compatible. Smaller amount of changes.
Cons: "ugly" digit suffix to interface names.
I think (3) is a front runner. For (2) the "medicine is worse than the
cure". (1) I would do for selfish reasons, but we'd upset various
communities, possibly to the point of mutiny.
However, I am not active in maint of framework. I will leave the
decision to others, but state that my highest concern is a timeline. I
will vote..... if (1) is vetoed I'll vote for (3) over (2) and I really
believe that loading a gun and shooting a package to avoid a "2" suffix
is over the top.
- Paul
>Paul:
>
>I don't agree with point concerning the absence of the
>word "Component" - a component is an abstract thing - more
>abstract than the computational descriptions we can put
>into Java interfaces. In fact I think the absence of the
>word component in the interface name clarifies (for me) the
>function from a computational perspective as distinct from
>the role of the interface in the overall component
>abstraction.
>
>Its Sunday afternoon and there are just too many big word
>in that paragraph - time I had another glass of wine!
>
>Cheers, Steve.
>
>
>>-----Original Message-----
>>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>>Sent: Sunday, 10 February, 2002 14:25
>>To: Avalon Developers List
>>Subject: Re: ComponentManager interface
>>
>>
>>Peter,
>>
>>>>Composable2, ComponentManager2 ?
>>>>
>>>ewww - runaway, runaway ;)
>>>
>>I knew we we going round in circles dude.... You're the one pushing
>>for 'Component becomes Object' (by implication) then backing away ;-)
>>
>>I don't like Stephens new ServiceXXXX stuff. I mean it is good. No it
>>is perfect but for the absense of the word "Component".
>>
>>We are not without precident, all these from JDK1.4 :
>>
>> LayoutManager2
>> GlyphPainter2
>> Parser2 (Crimson)
>> ElementNode2
>> NamespaceSupport2
>>
>><fx> ducks from Peter's bullets </fx>
>>
>>Packages Evolve. Lets understand that. We have no versioning built
>>into Java in the sense that two versions of the same API could
>>interoperate in the same classloader/classpath. In ten years time we
>>will have loads of dead packages (java.io is example) or loads of
>>suffixed classes/interfaces. We could migrate all functionality
>>immediately to the "2" versions and for the original versions have a
>>hand crafted proxy that routes all calls through to the new one.
>>
>>It is one strategy that will be taken with AWT in the end I guess.
>> Sun/Netacape built Swing on top of the AWT primatives, but kept AWTs
>>own heavyweight comps. Sun could obsolete AWT and or have a near enough
>>pure Java "AWT2" that AWT routes through to. In fact AWT could route
>>through to Swing, more or less completely hiding the experience. In
>>that version of the graphic toolkit all Swing would need from the
>>iunderlying OS would be mouse, kbd and "rectangle reservation" graphics
>>support. Swing could sit small OSs that have no advanced graphics API.
>> Sigh... Java's original Component model ;-)
>>
>>- Paul
>>
>>
>>
>>--
>>To unsubscribe, e-mail:
>>
><ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
Paul:
I don't agree with point concerning the absence of the
word "Component" - a component is an abstract thing - more
abstract than the computational descriptions we can put
into Java interfaces. In fact I think the absence of the
word component in the interface name clarifies (for me) the
function from a computational perspective as distinct from
the role of the interface in the overall component
abstraction.
Its Sunday afternoon and there are just too many big word
in that paragraph - time I had another glass of wine!
Cheers, Steve.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Sunday, 10 February, 2002 14:25
> To: Avalon Developers List
> Subject: Re: ComponentManager interface
>
>
> Peter,
>
> >>Composable2, ComponentManager2 ?
> >>
> >
> >ewww - runaway, runaway ;)
> >
> I knew we we going round in circles dude.... You're the one pushing
> for 'Component becomes Object' (by implication) then backing away ;-)
>
> I don't like Stephens new ServiceXXXX stuff. I mean it is good. No it
> is perfect but for the absense of the word "Component".
>
> We are not without precident, all these from JDK1.4 :
>
> LayoutManager2
> GlyphPainter2
> Parser2 (Crimson)
> ElementNode2
> NamespaceSupport2
>
> <fx> ducks from Peter's bullets </fx>
>
> Packages Evolve. Lets understand that. We have no versioning built
> into Java in the sense that two versions of the same API could
> interoperate in the same classloader/classpath. In ten years time we
> will have loads of dead packages (java.io is example) or loads of
> suffixed classes/interfaces. We could migrate all functionality
> immediately to the "2" versions and for the original versions have a
> hand crafted proxy that routes all calls through to the new one.
>
> It is one strategy that will be taken with AWT in the end I guess.
> Sun/Netacape built Swing on top of the AWT primatives, but kept AWTs
> own heavyweight comps. Sun could obsolete AWT and or have a near enough
> pure Java "AWT2" that AWT routes through to. In fact AWT could route
> through to Swing, more or less completely hiding the experience. In
> that version of the graphic toolkit all Swing would need from the
> iunderlying OS would be mouse, kbd and "rectangle reservation" graphics
> support. Swing could sit small OSs that have no advanced graphics API.
> Sigh... Java's original Component model ;-)
>
> - Paul
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager interface
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>Composable2, ComponentManager2 ?
>>
>
>ewww - runaway, runaway ;)
>
I knew we we going round in circles dude.... You're the one pushing
for 'Component becomes Object' (by implication) then backing away ;-)
I don't like Stephens new ServiceXXXX stuff. I mean it is good. No it
is perfect but for the absense of the word "Component".
We are not without precident, all these from JDK1.4 :
LayoutManager2
GlyphPainter2
Parser2 (Crimson)
ElementNode2
NamespaceSupport2
<fx> ducks from Peter's bullets </fx>
Packages Evolve. Lets understand that. We have no versioning built
into Java in the sense that two versions of the same API could
interoperate in the same classloader/classpath. In ten years time we
will have loads of dead packages (java.io is example) or loads of
suffixed classes/interfaces. We could migrate all functionality
immediately to the "2" versions and for the original versions have a
hand crafted proxy that routes all calls through to the new one.
It is one strategy that will be taken with AWT in the end I guess.
Sun/Netacape built Swing on top of the AWT primatives, but kept AWTs
own heavyweight comps. Sun could obsolete AWT and or have a near enough
pure Java "AWT2" that AWT routes through to. In fact AWT could route
through to Swing, more or less completely hiding the experience. In
that version of the graphic toolkit all Swing would need from the
iunderlying OS would be mouse, kbd and "rectangle reservation" graphics
support. Swing could sit small OSs that have no advanced graphics API.
Sigh... Java's original Component model ;-)
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager interface
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>what about EOB - does it access services via
>interfaces?
>
Yes. 'Object lookup(String name) throws ComponentException'
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
On Mon, 11 Feb 2002 09:07, Berin Loritsch wrote:
> Stephen McConnell wrote:
> > Pete suggested:
> >>framework.service.ServiceManager
> >>framework.service.Servicable
> >
> > This is perfect!
> > Steve.
>
> Not for what has been discussed. I.e. a lightweight form of JNDI.
So we are going towards that ?
> Service is even more narrow than Component, as Service is a specific
> type of Component.
Correct but it is inline with the way all our projects use it. I haven't
looked closely but I assume all the ones that develoeprs from here are
involved with enforce this contract. ie phoenix and thus james explictly
enforces it, as does the ant proposal - IIRC Cocoon does not require it but
it is the way that it is used - what about EOB - does it access services via
interfaces?
--
Cheers,
Pete
*---------------------------------------------------------*
| Programming today is a race between software engineers |
| striving to build bigger and better idiot-proof |
| programs,and the universe trying to produce bigger and |
| better idiots. So far, the universe is winning. |
| - Richard Cook |
*---------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Pete suggested:
>
>
>>framework.service.ServiceManager
>>framework.service.Servicable
>>
>
> This is perfect!
> Steve.
>
>
Not for what has been discussed. I.e. a lightweight form of JNDI.
Service is even more narrow than Component, as Service is a specific
type of Component.
----------------------------------------------------
Sign Up for NetZero Platinum Today
Only $9.95 per month!
http://my.netzero.net/s/signup?r=platinum&refcd=PT97
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
I have just posted 5 files under src/proposal for consideration.
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon/src/proposal/service/
These include:
Serviceable - equivalent to Composable
ServiceManager - equivalent to ComponentManager
ServiceException - equivalent to ComponentException
DefaultServiceManager - equivalent to DefaultComponentManager
LifecycleHelper - updated version of the Phoenix lifecycle runner
that handles Serviceable object
Let me know what your think!
Cheers, Steve.
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Sunday, 10 February, 2002 04:21
> To: Avalon Developers List
> Subject: RE: ComponentManager interface
>
>
>
> Pete suggested:
>
> > framework.service.ServiceManager
> > framework.service.Servicable
>
> This is perfect!
> Steve.
>
>
> > -----Original Message-----
> > From: Peter Donald [mailto:peter@apache.org]
> > Sent: Sunday, 10 February, 2002 02:39
> > To: Avalon Developers List
> > Subject: Re: ComponentManager interface
> >
> >
> > On Sun, 10 Feb 2002 09:12, Paul Hammant wrote:
> > > Peter,
> > >
> > > >> (c) change the argument type on the release from
> > > >> Component to Object.
> > > >
> > > >Unfortunately that would break backwards compatability which I
> > am -1 on ;(
> > > >The only real solution is to use a new package or set of new
> > classnames.
> > >
> > > Composable2, ComponentManager2 ?
> >
> > ewww - runaway, runaway ;)
> >
> > Repeating a bit from a previous mail...
> >
> > ++++++++++++++++++++++++++++++++
> > I have an extreme allergy of postfixing things with numbers.
> Way too many
> > years working with MS tech to like that :) How about we add a new
> > package or
> > maybe just a new name. Possible candidates include
> >
> >
> > framework.component2.ComponentManager
> > framework.component2.Composable
> >
> > framework.service.ServiceManager
> > framework.service.Servicable
> >
> > framework.service.ServiceDirectory
> > framework.service.ServiceEnabled
> > ...
> >
> > --
> > Cheers,
> >
> > Pete
> >
> > "The ability to quote is a serviceable substitute for wit." -- Maugham
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
Pete suggested:
> framework.service.ServiceManager
> framework.service.Servicable
This is perfect!
Steve.
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Sunday, 10 February, 2002 02:39
> To: Avalon Developers List
> Subject: Re: ComponentManager interface
>
>
> On Sun, 10 Feb 2002 09:12, Paul Hammant wrote:
> > Peter,
> >
> > >> (c) change the argument type on the release from
> > >> Component to Object.
> > >
> > >Unfortunately that would break backwards compatability which I
> am -1 on ;(
> > >The only real solution is to use a new package or set of new
> classnames.
> >
> > Composable2, ComponentManager2 ?
>
> ewww - runaway, runaway ;)
>
> Repeating a bit from a previous mail...
>
> ++++++++++++++++++++++++++++++++
> I have an extreme allergy of postfixing things with numbers. Way too many
> years working with MS tech to like that :) How about we add a new
> package or
> maybe just a new name. Possible candidates include
>
>
> framework.component2.ComponentManager
> framework.component2.Composable
>
> framework.service.ServiceManager
> framework.service.Servicable
>
> framework.service.ServiceDirectory
> framework.service.ServiceEnabled
> ...
>
> --
> Cheers,
>
> Pete
>
> "The ability to quote is a serviceable substitute for wit." -- Maugham
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
On Sun, 10 Feb 2002 09:12, Paul Hammant wrote:
> Peter,
>
> >> (c) change the argument type on the release from
> >> Component to Object.
> >
> >Unfortunately that would break backwards compatability which I am -1 on ;(
> >The only real solution is to use a new package or set of new classnames.
>
> Composable2, ComponentManager2 ?
ewww - runaway, runaway ;)
Repeating a bit from a previous mail...
++++++++++++++++++++++++++++++++
I have an extreme allergy of postfixing things with numbers. Way too many
years working with MS tech to like that :) How about we add a new package or
maybe just a new name. Possible candidates include
framework.component2.ComponentManager
framework.component2.Composable
framework.service.ServiceManager
framework.service.Servicable
framework.service.ServiceDirectory
framework.service.ServiceEnabled
...
--
Cheers,
Pete
"The ability to quote is a serviceable substitute for wit." -- Maugham
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
And if you drop the word Component you end up with:
GenericManager
GenericComposable
Another 0.02 EUROs to add to the pot.
Steve.
> -----Original Message-----
> From: Gerhard Froehlich [mailto:g-froehlich@gmx.de]
> Sent: Sunday, 10 February, 2002 01:27
> To: Avalon Developers List
> Subject: RE: ComponentManager interface
>
>
> Hmm how about GenericComponentManager and
> GenericComposable.
> Generic because it returns the Object types...
>
> my 0.02 EURO Cents
>
> ~Gerhard
>
> "The most important question when any new
> computer architecture is introduced is 'So what?'"
>
> >-----Original Message-----
> >From: Stephen McConnell [mailto:mcconnell@apache.org]
> >Sent: Sunday, February 10, 2002 12:18 AM
> >To: Avalon Developers List
> >Subject: RE: ComponentManager interface
> >
> >
> >
> >However - after browsing around in Phoenix sources, I'm thinking to
> >myself that Paul's suggestion of Composable2, ComponentManager2 may
> >be an all-round simpler solution.
> >
> >Steve.
> >
> >> -----Original Message-----
> >> From: Stephen McConnell [mailto:mcconnell@apache.org]
> >> Sent: Saturday, 09 February, 2002 23:30
> >> To: Avalon Developers List
> >> Subject: RE: ComponentManager interface
> >>
> >>
> >>
> >> How about a package "org.apache.avalon.framework.manager"
> >> containing:
> >>
> >> Composable
> >> ComponentManager
> >> ComponentSelector
> >> DefaultComponentManager
> >> DefaultComponetSelector
> >> ComponentException
> >>
> >> This would mirror the existing "component" package that
> >> Component would be replaced with Object. Its then
> >> drop-dead-easy to update things.
> >>
> >> Steve.
> >>
> >> > -----Original Message-----
> >> > From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> >> > Sent: Saturday, 09 February, 2002 23:13
> >> > To: Avalon Developers List
> >> > Subject: Re: ComponentManager interface
> >> >
> >> >
> >> > Peter,
> >> >
> >> > >>
> >> > >> (c) change the argument type on the release from
> >> > >> Component to Object.
> >> > >>
> >> > >
> >> > >Unfortunately that would break backwards compatability which I
> >> > am -1 on ;(
> >> > >The only real solution is to use a new package or set of new
> >> classnames.
> >> > >
> >> >
> >> > Composable2, ComponentManager2 ?
> >> >
> >> > - Paul
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > To unsubscribe, e-mail:
> >> > <ma...@jakarta.apache.org>
> >> > For additional commands, e-mail:
> >> > <ma...@jakarta.apache.org>
> >> >
> >>
> >> --
> >> To unsubscribe, e-mail:
> >> <ma...@jakarta.apache.org>
> >> For additional commands, e-mail:
> >> <ma...@jakarta.apache.org>
> >>
> >
> >--
> >To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
>For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ComponentManager interface
Posted by Gerhard Froehlich <g-...@gmx.de>.
Hmm how about GenericComponentManager and
GenericComposable.
Generic because it returns the Object types...
my 0.02 EURO Cents
~Gerhard
"The most important question when any new
computer architecture is introduced is 'So what?'"
>-----Original Message-----
>From: Stephen McConnell [mailto:mcconnell@apache.org]
>Sent: Sunday, February 10, 2002 12:18 AM
>To: Avalon Developers List
>Subject: RE: ComponentManager interface
>
>
>
>However - after browsing around in Phoenix sources, I'm thinking to
>myself that Paul's suggestion of Composable2, ComponentManager2 may
>be an all-round simpler solution.
>
>Steve.
>
>> -----Original Message-----
>> From: Stephen McConnell [mailto:mcconnell@apache.org]
>> Sent: Saturday, 09 February, 2002 23:30
>> To: Avalon Developers List
>> Subject: RE: ComponentManager interface
>>
>>
>>
>> How about a package "org.apache.avalon.framework.manager"
>> containing:
>>
>> Composable
>> ComponentManager
>> ComponentSelector
>> DefaultComponentManager
>> DefaultComponetSelector
>> ComponentException
>>
>> This would mirror the existing "component" package that
>> Component would be replaced with Object. Its then
>> drop-dead-easy to update things.
>>
>> Steve.
>>
>> > -----Original Message-----
>> > From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>> > Sent: Saturday, 09 February, 2002 23:13
>> > To: Avalon Developers List
>> > Subject: Re: ComponentManager interface
>> >
>> >
>> > Peter,
>> >
>> > >>
>> > >> (c) change the argument type on the release from
>> > >> Component to Object.
>> > >>
>> > >
>> > >Unfortunately that would break backwards compatability which I
>> > am -1 on ;(
>> > >The only real solution is to use a new package or set of new
>> classnames.
>> > >
>> >
>> > Composable2, ComponentManager2 ?
>> >
>> > - Paul
>> >
>> >
>> >
>> >
>> > --
>> > To unsubscribe, e-mail:
>> > <ma...@jakarta.apache.org>
>> > For additional commands, e-mail:
>> > <ma...@jakarta.apache.org>
>> >
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
However - after browsing around in Phoenix sources, I'm thinking to
myself that Paul's suggestion of Composable2, ComponentManager2 may
be an all-round simpler solution.
Steve.
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Saturday, 09 February, 2002 23:30
> To: Avalon Developers List
> Subject: RE: ComponentManager interface
>
>
>
> How about a package "org.apache.avalon.framework.manager"
> containing:
>
> Composable
> ComponentManager
> ComponentSelector
> DefaultComponentManager
> DefaultComponetSelector
> ComponentException
>
> This would mirror the existing "component" package that
> Component would be replaced with Object. Its then
> drop-dead-easy to update things.
>
> Steve.
>
> > -----Original Message-----
> > From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> > Sent: Saturday, 09 February, 2002 23:13
> > To: Avalon Developers List
> > Subject: Re: ComponentManager interface
> >
> >
> > Peter,
> >
> > >>
> > >> (c) change the argument type on the release from
> > >> Component to Object.
> > >>
> > >
> > >Unfortunately that would break backwards compatability which I
> > am -1 on ;(
> > >The only real solution is to use a new package or set of new
> classnames.
> > >
> >
> > Composable2, ComponentManager2 ?
> >
> > - Paul
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
How about a package "org.apache.avalon.framework.manager"
containing:
Composable
ComponentManager
ComponentSelector
DefaultComponentManager
DefaultComponetSelector
ComponentException
This would mirror the existing "component" package that
Component would be replaced with Object. Its then
drop-dead-easy to update things.
Steve.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Saturday, 09 February, 2002 23:13
> To: Avalon Developers List
> Subject: Re: ComponentManager interface
>
>
> Peter,
>
> >>
> >> (c) change the argument type on the release from
> >> Component to Object.
> >>
> >
> >Unfortunately that would break backwards compatability which I
> am -1 on ;(
> >The only real solution is to use a new package or set of new classnames.
> >
>
> Composable2, ComponentManager2 ?
>
> - Paul
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager interface
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>
>> (c) change the argument type on the release from
>> Component to Object.
>>
>
>Unfortunately that would break backwards compatability which I am -1 on ;(
>The only real solution is to use a new package or set of new classnames.
>
Composable2, ComponentManager2 ?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
On Sat, 9 Feb 2002 21:18, Stephen McConnell wrote:
> Proposal:
>
> (a) mark the lookup operation as deprecated
> (b) add a new method "resolve" that is
> functionally equivalent to "lookup" but returns
> Object instead of Component
> (c) change the argument type on the release from
> Component to Object.
Unfortunately that would break backwards compatability which I am -1 on ;(
The only real solution is to use a new package or set of new classnames.
--
Cheers,
Pete
---------------------------------------------
We shall not cease from exploration, and the
end of all our exploring will be to arrive
where we started and know the place for the
first time -- T.S. Eliot
---------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager interface
Posted by Leif Mortenson <le...@silveregg.co.jp>.
Leo Sutic wrote:
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Proposal:
>>
>> (a) mark the lookup operation as deprecated
>> (b) add a new method "resolve" that is
>> functionally equivalent to "lookup" but returns
>> Object instead of Component
>>
>
> Breaks compatibility - no implementation of ComponentManager will
> work unless edited and recompiled.
>
>
>> (c) change the argument type on the release from
>> Component to Object.
>>
>
>
> Since this change will break backwards compatibility, might as well
> do it without adding new methods. Just replace Component with Object
> in the CM interface and release it as 4.2. Everyone must recompile,
> but that should be about it.
Not quite that simple. Not sure how likely it is, but if someone has
code like the following, this change will break things:
Component component = manager.lookup(name);
It would need to be changed to:
Component component = (Component)manager.lookup(name);
This will probably not be a problem though. It seems likely that in
most cases other than avalon classes, the return value is already being
cast to a specific class. Something like:
DataSourceComponent dataSource =
(DataSourceComponent)manager.lookup(name)
Thoughts?
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager interface
Posted by Paul Hammant <Pa...@yahoo.com>.
Leo,
>> (c) change the argument type on the release from
>> Component to Object.
>>
>
>
>Since this change will break backwards compatibility, might as well
>do it without adding new methods. Just replace Component with Object
>in the CM interface and release it as 4.2. Everyone must recompile,
>but that should be about it.
>
This is my vote too. Hit this as a special case and release before the
major addition of other methods that would justify a major version
incrament.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ComponentManager interface
Posted by Gerhard Froehlich <g-...@gmx.de>.
Hi,
>> Proposal:
>>
>> (a) mark the lookup operation as deprecated
>> (b) add a new method "resolve" that is
>> functionally equivalent to "lookup" but returns
>> Object instead of Component
>
>Breaks compatibility - no implementation of ComponentManager will
>work unless edited and recompiled.
>
>> (c) change the argument type on the release from
>> Component to Object.
>
>
>Since this change will break backwards compatibility, might as well
>do it without adding new methods. Just replace Component with Object
>in the CM interface and release it as 4.2. Everyone must recompile,
>but that should be about it.
Alarm bells starting to ring in my head. Breaking backward compability
is really bad, bad ;)
Sorry I'm -1 on this...
~Gerhard
"God put me on this Earth to accomplish a certain number of things.
Right now, I am so far behind I shall never die."
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ComponentManager interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Proposal:
>
> (a) mark the lookup operation as deprecated
> (b) add a new method "resolve" that is
> functionally equivalent to "lookup" but returns
> Object instead of Component
Breaks compatibility - no implementation of ComponentManager will
work unless edited and recompiled.
> (c) change the argument type on the release from
> Component to Object.
Since this change will break backwards compatibility, might as well
do it without adding new methods. Just replace Component with Object
in the CM interface and release it as 4.2. Everyone must recompile,
but that should be about it.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
Proposal:
(a) mark the lookup operation as deprecated
(b) add a new method "resolve" that is
functionally equivalent to "lookup" but returns
Object instead of Component
(c) change the argument type on the release from
Component to Object.
Steve.
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Saturday, 09 February, 2002 09:06
> To: Avalon Developers List
> Subject: Re: ComponentManager interface
>
>
> On Sat, 9 Feb 2002 11:53, Stephen McConnell wrote:
> > Given that Component's existence is under considered of being
> > depreciated, can anyone provide some hints as to probability
> > and timeframe of the ComponentManager.lookup operation returning
> > Object instead of Component. The reason I'm asking is that such
> > a change would be very beneficial to the things I'm working on
> > that do not and will never implement Component
> > (e.g. org.omg.CORBA.Object).
>
> Im in a similar position in a couple of projects where I ended up
> creating
> another siilar interface. So I guess that makes 3 committers who would
> benefit from something like this. However we can't afford to
> break anything
> in Cocoon land. So maybe we just create something that is a stop-gap till
> Framework 5.0 ?
>
> --
> Cheers,
>
> Pete
>
> --------------------------------------------------
> you've made a dangerous leap right over common
> sense, like some kind of metaphysical Evil Knievel
> --------------------------------------------------
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
On Sat, 9 Feb 2002 11:53, Stephen McConnell wrote:
> Given that Component's existence is under considered of being
> depreciated, can anyone provide some hints as to probability
> and timeframe of the ComponentManager.lookup operation returning
> Object instead of Component. The reason I'm asking is that such
> a change would be very beneficial to the things I'm working on
> that do not and will never implement Component
> (e.g. org.omg.CORBA.Object).
Im in a similar position in a couple of projects where I ended up creating
another siilar interface. So I guess that makes 3 committers who would
benefit from something like this. However we can't afford to break anything
in Cocoon land. So maybe we just create something that is a stop-gap till
Framework 5.0 ?
--
Cheers,
Pete
--------------------------------------------------
you've made a dangerous leap right over common
sense, like some kind of metaphysical Evil Knievel
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>