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...@apache.org> on 2002/02/11 16:41:28 UTC
[VOTE] RE: ComponentManager interface
This brings us down to options (3) and (4), both involving
creation of quasi parallel interfaces and implementation
of ComponentManger and DefaultComponentManager which deal
with Object as distinct from Component.
I've broken this down into three options which we can vote
on, the first option is to go ahead with the proposed
framework/service package. The second option is to go ahead
but defer a decision on the package name pending further
discussion, and the third option is to add a new interface and
implementation to the current component package.
(A) Clone interface, implementation, and exception into a
new package org.apache.avalon.framework.service
(B) Clone interface, implementation, and exception into a
new package and defer package, interface and
implementation naming for further discussion.
(C) Clone interface, implementation, and exception under
the existing framework/component package and defer
interface and implementation naming for further
discussion.
To kick things off, here is my vote:
(A) +1
(B) +0,
(C) -0
Cheers, Steve.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Monday, 11 February, 2002 15:50
> To: Avalon Developers List
> Subject: Re: ComponentManager interface
>
>
> Stephen,
>
> Issues concerning getObjectMap() and hasObject() are valid. I'll drop
> my pushing for resolve(..), but will not accept that /it/ was the same
> level of "backwards incopatible" as changing Comp to Obj on lookup(..)
>
> I am most interested in timeline again...
>
> - Paul.
>
> >Paul:
> >
> >Aside from the backwards incompatible question there are some
> >nasties in taking approach of the addition of a "resolve"
> >method. If you try working up a modified version of
> >ComponentManager (which I did and threw away), you end up
> >having to add "getObjectMap" and "hasObject" because
> >"getComponentMap" only returns the map for Component
> >instances and "hasComponent" returns TRUE only if the object
> >is a Component. Secondly, you need to make a decision
> >concerning (a) maintaining one or two HashMaps. If you
> >maintain one HashMap containing objects you then need to
> >put in [instanceof Component] on "hasComponent" and "lookup"
> >and you need filter out non-Component references when
> >returning a Map from getComponentMap. If you choose to use
> >two HashMaps you then have to decide if your going to duplicate
> >component reference in you object map or manage the creation
> >of a combined component/object map from the getObjectMap
> >method. It's not brain surgery - just brain damage - you end
> >up with multiple methods doing basically the same thing and
> >turning the implementation into something confusing.
> >
> >Steve.
> >
> >
> >>-----Original Message-----
> >>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> >>Sent: Monday, 11 February, 2002 12:24
> >>To: Avalon Developers List
> >>Subject: Re: ComponentManager interface
> >>
> >>
> >>Peter
> >>
> >>>>>>(2) Create a new method in the same ComponentManager interface
> >>>>>>
> >>>>>> variations : "lookup2", "resolve"
> >>>>>>
> >>>>>-1 - backwards incompatible
> >>>>>
> >>>>So interfaces, once defined are immutable?
> >>>>
> >>>You can demote parameters to demothds and add constants but
> >>>
> >>little else. ie
> >>
> >>>Get it right first time or not all :)
> >>>
> >>> Hmmm, I think you made a
> >>>
> >>>>mistake here. Adding a method was "relaxed" as an
> incompatability when
> >>>>JDK migrated from 1.1 to 1.2. Before then. any diffrence in
> any method
> >>>>as illustrated by some checksum/hash/serialID was enough to
> make the JVM
> >>>>barf. After that it would consider methods on a case by case basis
> >>>>before deciding to barf. Compilation is different of course,
> but I will
> >>>>not accept the two word phrase "backwards incompatible" for this.
> >>>>
> >>>Not sure what you are going on about here. I mean backwards
> incompatible
> >>>because if you made either change you would subsequently break
> >>>
> >>oodles of code
> >>
> >>>including, ExcaliburComponentManager, Cocoon, Phoenix, Myrmidon
> >>>
> >>and anything
> >>
> >>>else that defines their own CM or relies on return type.
> >>>
> >>>So are you saying this is not a problem or what?
> >>>
> >>Yes, it is not a problem. The (2) proposition is about an *additional*
> >>method called "lookup2" or "resolve".
> >>
> >>>>>o +1 to doing something backwards compatible in framework4.x
> >>>>>
> >>>>Given that (2) is backwards compatible in so far as code compiled for
> >>>>the current ComponentManager would continue to work for a
> future version
> >>>>with *extra* methods, is (2) back in the running?
> >>>>
> >>>No - it will break Phoenix and any other code that defines a
> custom CM ;)
> >>>
> >>Phoenix merely has to implement "resolve" in addition to the "lookup"
> >>method. Not brain surgery. It is a compile time only issue.
> >>
> >>I could make all the compatability changes myself. For example if
> >>Cocoon had it's own impl of CompMgr, I could implement the new method.
> >> Get it to throw a RuntimeException knowing there is no part of the
> >>current Cocoon using it. Thus we have a version of Cocoon that will
> >>compile against the pre and post versions of framework. Which one the
> >>Cocoon team book in is up to them. I would change no other
> >>functionality. No up or down casting anywhere.
> >>
> >>Regards,
> >>
> >>- 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: [VOTE] RE: ComponentManager interface
Posted by Paul Hammant <Pa...@yahoo.com>.
Berin,
> I want to eventually add in a Query object ability--so we have two
> options.
>
> 1) The ServiceManager stays as is with the change that the key lookup
> is an Object instead of String (String is common case, but allows
> for Query object enhancement later).
-1
> 2) The ServiceManager has two methods: one String, and one Query object
+1
> interface ServiceManager
> {
> Object lookup( String role );
> Object lookup( String role, Parameters attributes );
> void release( Object component );
> }
This is good too.
> If we introduce this change, we won't be able to add the extra
> functionality
> later for the Query object.
I disagree. If you mark Query as subject to change, in fact the whole
package as subject to change, I would be quite happy to migrate EOB as
often as was needed.
I have no need of Query, so we could merely clone CompMgr into
ServiceMgr as Stephen says (so we can use it immediately) then negotiate
changes to it.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Paulo Gaspar wrote:
>>...but Map does allow potentially more efficient implementations.
>>
>
> For efficiency:
>
> interface ServiceManager
> {
> Object lookup( Object key );
> boolean hasService( Object key );
> void release( Object key );
> }
>
> IMO this provides the most efficient basic implementation and
> maximum flexibility.
It might allow too much flexibility. AIU, the contract surrounding
ServiceManager is basically:
MyThing mt = (MyThing) sm.lookup("com.things.MyThing");
I don't really see a way to express this with Object keys.
(: A ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] RE: ComponentManager interface
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Berin,
I wait a bit more until you read my answer to this one from
Stephen.
=;o)
Have fun,
Paulo
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, February 14, 2002 2:46 PM
> To: Avalon Developers List
> Cc: paulo.gaspar@krankikom.de
> Subject: Re: [VOTE] RE: ComponentManager interface
>
>
> Stephen McConnell wrote:
> > Paulo:
> >
> > I agree on the efficiency point, .. however the interface is
> > loosing something in terms of implicit clarity and potential for
> > consistent usage (it's starting to look more like hashtable
> > get/indexof/remove). I would prefer to move further towards an
> > interface that (a) expresses notions of service provision/
> > decommissioning more concretely and explicitly (i.e. closer to
> > yesterday), but (b) enhanced to address input from yourself,
> > Antti and Sylvain during the evening that touched on the
> > parallelism between lookup and hasXxxx. Thinking about the
> > parallelism issue for the last few hours as a result of those
> > comments leads me to the conclusion that non-parallel
> > lookup/hasXxxx effectively implies potentially unwarranted
> > implementation restrictions. A resolution could be the addition
> > of a supplementary hasXxxx method as shown below.
> >
> > interface ServiceManager
> > {
> > Object lookup( final String role );
> > Object lookup( final String role, Map policy );
> >
> > boolean hasService( final String role );
> > boolean hasService( final String role, Map policy ); <--
> addition ?
> >
> > void release( Object key );
> > }
> >
> > The addition of hasXxxxx( key, policy ) ensures that your not going
> > on a blind date. The boolean result of the operation should
> > semantically be quite clear in that TRUE hasXxxxx response should
> > indicate that within reasonable operating conditions, the lookup
> > operation will not fail. It is then up to implementations to resolve
> > decisions concerning ability to honour a service availability
> > commitment (potentially in the context supplied policy).
> >
> > What do you think?
>
>
> Sounds good.
>
>
> --
>
> "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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Paulo:
>
> I agree on the efficiency point, .. however the interface is
> loosing something in terms of implicit clarity and potential for
> consistent usage (it's starting to look more like hashtable
> get/indexof/remove). I would prefer to move further towards an
> interface that (a) expresses notions of service provision/
> decommissioning more concretely and explicitly (i.e. closer to
> yesterday), but (b) enhanced to address input from yourself,
> Antti and Sylvain during the evening that touched on the
> parallelism between lookup and hasXxxx. Thinking about the
> parallelism issue for the last few hours as a result of those
> comments leads me to the conclusion that non-parallel
> lookup/hasXxxx effectively implies potentially unwarranted
> implementation restrictions. A resolution could be the addition
> of a supplementary hasXxxx method as shown below.
>
> interface ServiceManager
> {
> Object lookup( final String role );
> Object lookup( final String role, Map policy );
>
> boolean hasService( final String role );
> boolean hasService( final String role, Map policy ); <-- addition ?
>
> void release( Object key );
> }
>
> The addition of hasXxxxx( key, policy ) ensures that your not going
> on a blind date. The boolean result of the operation should
> semantically be quite clear in that TRUE hasXxxxx response should
> indicate that within reasonable operating conditions, the lookup
> operation will not fail. It is then up to implementations to resolve
> decisions concerning ability to honour a service availability
> commitment (potentially in the context supplied policy).
>
> What do you think?
Sounds good.
--
"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: [VOTE] RE: ComponentManager interface
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Berin Loritsch wrote:
> Antti Koivunen wrote:
>>
>> Right. In a reply to Steve I actually suggested this:
>>
>> Object lookup( String role, Object policy );
>> Object hasService( String role, Object policy );
>>
>> which maintains the same flexibility, but doesn't limit the
>> performance or ease of use.
>
>
>
> This even works like you would expect by merging ComponentManager and
> ComponentSelector into one interface. The last time I proposed this I
> beleive Federico had a cow.
>
> This provides the ultimate simplicity for the simple cases (i.e. using
> a string for a hint), and the power for the complex cases (i.e.
> multidimensional lookup with a Map).
And it also allows the use of custom 'hint' objects of arbitrary
complexity for specific component types, while maintaining optimal
performance (hashCode(), equals()). The hint could be a simple String
just as well as something like java.awt.datatransfer.DataFlavor, and
both could be used with the same ServiceManager implementation.
(: A ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
Antti Koivunen wrote:
> Berin Loritsch wrote:
>
>>
>> The hint if anything should match the ComponentSelector idea, and be an
>> Object. Map (as an interface) provides a flexible N-dimensional lookup.
>
>
> Right. In a reply to Steve I actually suggested this:
>
> Object lookup( String role, Object policy );
> Object hasService( String role, Object policy );
>
> which maintains the same flexibility, but doesn't limit the performance
> or ease of use.
This even works like you would expect by merging ComponentManager and
ComponentSelector into one interface. The last time I proposed this I
beleive Federico had a cow.
This provides the ultimate simplicity for the simple cases (i.e. using
a string for a hint), and the power for the complex cases (i.e. multidimensional
lookup with a Map).
--
"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: [VOTE] RE: ComponentManager interface
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Berin Loritsch wrote:
>
> The hint if anything should match the ComponentSelector idea, and be an
> Object. Map (as an interface) provides a flexible N-dimensional lookup.
Right. In a reply to Steve I actually suggested this:
Object lookup( String role, Object policy );
Object hasService( String role, Object policy );
which maintains the same flexibility, but doesn't limit the performance
or ease of use.
(: A ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
Antti Koivunen wrote:
> Stephen McConnell wrote:
> <skip/>
>
>>
>> interface ServiceManager
>> {
>> Object lookup( final String role );
>> Object lookup( final String role, Map policy );
>>
>> boolean hasService( final String role );
>> boolean hasService( final String role, Map policy ); <-- addition ?
>>
>> void release( Object key );
>> }
>>
>> The addition of hasXxxxx( key, policy ) ensures that your not going on
>> a blind date.
>
>
> I agree, it's more consistent and required for something like:
>
> map.put("mime-type", "video/mpeg");
> boolean ok = sm.hasService(Codec.ROLE, map);
>
> There are many other cases where the policy/hint would just be a simple
> string. As the use of a Map has some performance implications, I might
> consider adding also:
>
> Object lookup( String role, String hint );
> boolean hasService( String role, String hint );
>
> The hint could be something simple, such as a mime-type, protocol or
> URL, but it would also allow the use of string queries, if necessary.
>
> What do you think?
The hint if anything should match the ComponentSelector idea, and be an
Object. Map (as an interface) provides a flexible N-dimensional lookup.
Of course with a Simple object reference, we can have the second dimension
(usually String hint) as well as any N-dimensional lookups (I haven't
run accross any real requirement for this yet....).
--
"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: [VOTE] RE: ComponentManager interface
Posted by Antti Koivunen <an...@users.sourceforge.net>.
This way the ServiceManager implementation could also be something
simple, such as:
void addService( String role, Object service );
void addService( String role, Map hintToService );
void addService( String role, Map hintToService, Object default );
This would actually be both flexible and efficient.
(: A ;)
Antti Koivunen wrote:
>
> Sure, as Map provides maximum flexibility. I also agree on the
> simplicity point, but I want to get all ideas in the open, as now is the
> right time for discussion. The point of the previous suggestion was ease
> of use and performance. I guess we should also consider this:
>
> Object lookup( String role, Object policy );
> Object hasService( String role, Object policy );
>
> It would give us the same flexibility, but allow potentially more
> efficient implementations. Too much of a generalization?
>
> (: A ;)
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Stephen McConnell wrote:
>
> Ummmm,... I'd like to avoid the additional methods if possible. The
> fundamently attractive thing about the whole of the Avalon Framework
> is this amazing combination of simplicity and functionality. Maybe I'm
> being over-sensertive but I'm very aware of the fact that we are have
> already almost doubled the number of operations relative to CM - which
> leaves me with the question - can you do without it?
Sure, as Map provides maximum flexibility. I also agree on the
simplicity point, but I want to get all ideas in the open, as now is the
right time for discussion. The point of the previous suggestion was ease
of use and performance. I guess we should also consider this:
Object lookup( String role, Object policy );
Object hasService( String role, Object policy );
It would give us the same flexibility, but allow potentially more
efficient implementations. Too much of a generalization?
(: A ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Hi there,
I'd like to get one thing cleared out: what is the conceptual difference
between ServiceManager and ComponentManager? AIU, ServiceManager
surfaced as a backwards compatible replacement for ComponentManager.
AFAIK, they are both mainly about:
"Find me a component/service/object that matches the
specified role, i.e. implements certain interface."
I can imagine the implementation and configuration being almost
identical, so (why) do we actually need both?
(: A ;)
Stephen McConnell wrote:
<skip/>> 1. ServiceManager
> - this is relatively stable relative to yesterdays
> discussions
> - last nights input raised the need for a parallel
> hasXxxx operation that takes a Map as an additional
> argument - paralleling lookup(String, Map )
> semantics
>
> interface ServiceManager
> {
> Object lookup( String role );
> Object lookup( String role, Map policy );
> boolean hasService( String role );
> boolean hasService( String role, Map policy );
> void release( Object key );
> }
>
> 2. ComponentManager
> - resurfacing of CM has been driven by what appears to be
> separation of concerns between service decommissioning
> as distinct from needs of referenced managed component
> (hence the appearance of Object as token in the interface
> below)
> - this is being discussed as a complementary interface to
> the ServiceManger described above
>
> interface ComponentManager
> {
> Object lookup( Object token, String role );
> Object lookup( Object token, String role, Map policy );
> boolean hasComponent(Object role );
> void release( Object component );
> void releaseAll( Object token );
> }
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
inline comments....
>>Can someone do a rollup of proposed alternative with pros and cons
>>please...... it is difficult to follow all the strands.
>>
>
>
>Here is an attempt to pull a few string together.
>
>There appear to be two primary threads of though/discussion.
>Here is a somewhat "normalised" version of the direction/scope of
>discussions as I see them (so please jump in and correct me if
>I'm missing anything dramatic). I'm assuming that we are all ok
>with the Map type as opposed to Parameter, that there appears to
>be a reasonable consensus that there are different concerns for
>"service" managed versus "reference" managed components which
>seem to be gravitating towards the ServiceManager and
>ComponentManager respectively. I think its fair to say that the
>ServiceManager is for all practical purposes stable as far as
>principals are concerned. The ComponentManager discussion are
>more recent and a will probably need another couple of laps
>around the garden before everything is clear.
>
> 1. ServiceManager
> - this is relatively stable relative to yesterdays
> discussions
> - last nights input raised the need for a parallel
> hasXxxx operation that takes a Map as an additional
> argument - paralleling lookup(String, Map )
> semantics
>
> interface ServiceManager
> {
> Object lookup( String role );
> Object lookup( String role, Map policy );
> boolean hasService( String role );
> boolean hasService( String role, Map policy );
> void release( Object key );
> }
>
> 2. ComponentManager
> - resurfacing of CM has been driven by what appears to be
> separation of concerns between service decommissioning
> as distinct from needs of referenced managed component
> (hence the appearance of Object as token in the interface
> below)
> - this is being discussed as a complementary interface to
> the ServiceManger described above
>
> interface ComponentManager
> {
> Object lookup( Object token, String role );
> Object lookup( Object token, String role, Map policy );
> boolean hasComponent(Object role );
> void release( Object component );
> void releaseAll( Object token );
> }
>
Quite a nice summary. Is this everyone's opinion?
Looking at these two, I am still not convinced that we are talking about
two different things. First off, ComponentManager will not be changed
again (NBC : NotBackCompat(TM)). Secondly if SM took Object instead of
String, they are more similar. "Policy" I have no opinion on as I do
not need it.
>As Pete has frequently pointed out, I need to exercise my commit
>muscles. As mentioned about - SM seems stable - CM appears to
>need some fine tuning. I would like to go ahead and flex these new
>found muscles by moving SM in the framework and committing the
>Phoenix updates. However, being the almost newest committer on
>the block I'll follow your lead.
>
I'd hold off dude. We need to bring everyone on the same path I think.
We have three people that need something on the KISS principle now, but
I think we should respect those more willing to apply patterns, at least
for a few more days.
What I Need now -----> Object lookup(String name) throws..
What I would accept ----> Object lookup(Object key) throws..
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] RE: ComponentManager interface
Posted by Paulo Gaspar <pa...@krankikom.de>.
A couple of remarks inline, especially on the CM:
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Thursday, February 14, 2002 12:42 PM
>
> On Thu, 14 Feb 2002 20:51, Stephen McConnell wrote:
> >
<SNIP/>
> >
> > interface ServiceManager
> > {
> > Object lookup( String role );
> > Object lookup( String role, Map policy );
> > boolean hasService( String role );
> > boolean hasService( String role, Map policy );
> > void release( Object key );
> > }
>
> Im not sure release() is needed in a Servicemanager. Release was
> originally
> added to serve the need that is covered by the below interface.
> And as such is it really needed ?
Yeah, my understanding was that services do not need to be
released! Isn't a service always thread safe???
> >
<SNIP/>
> >
> > interface ComponentManager
> > {
> > Object lookup( Object token, String role );
> > Object lookup( Object token, String role, Map policy );
> > boolean hasComponent(Object role );
> > void release( Object component );
> > void releaseAll( Object token );
> > }
Shouldn't
boolean hasComponent( Object role );
actually be
boolean hasComponent( String role );
I am also missing a
boolean hasComponent( String role, Map policy );
In my CM I also have a
/** releases all requested components not yet released */
void releaseAll();
...although I only ever used it inside its own dispose() code!
So, what I am saying is that maybe it should be more like;
interface ComponentManager
{
Object lookup( Object token, String role );
Object lookup( Object token, String role, Map policy );
boolean hasComponent( String role );
boolean hasComponent( String role, Map policy );
void release( Object component );
void releaseAll( Object token );
/** releases all requested components not yet released */
void releaseAll();
}
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
On Thu, 14 Feb 2002 20:51, Stephen McConnell wrote:
> 1. ServiceManager
> - this is relatively stable relative to yesterdays
> discussions
> - last nights input raised the need for a parallel
> hasXxxx operation that takes a Map as an additional
> argument - paralleling lookup(String, Map )
> semantics
>
> interface ServiceManager
> {
> Object lookup( String role );
> Object lookup( String role, Map policy );
> boolean hasService( String role );
> boolean hasService( String role, Map policy );
> void release( Object key );
> }
Im not sure release() is needed in a Servicemanager. Release was originally
added to serve the need that is covered by the below interface. And as such
is it really needed ?
> 2. ComponentManager
> - resurfacing of CM has been driven by what appears to be
> separation of concerns between service decommissioning
> as distinct from needs of referenced managed component
> (hence the appearance of Object as token in the interface
> below)
> - this is being discussed as a complementary interface to
> the ServiceManger described above
>
> interface ComponentManager
> {
> Object lookup( Object token, String role );
> Object lookup( Object token, String role, Map policy );
> boolean hasComponent(Object role );
> void release( Object component );
> void releaseAll( Object token );
> }
--
Cheers,
Pete
*--------------------------------*
| Every rule has an exception, |
| except the rule of exceptions. |
*--------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> ><snip/> Maybe I'm
> >being over-sensertive but I'm very aware of the fact that we are have
> >already almost doubled the number of operations relative to CM - which
> >leaves me with the question - can you do without it?
> >
> I could not agree more. Don't make me post that "What the user
> wanted" cartoon again.
>
> Can someone do a rollup of proposed alternative with pros and cons
> please...... it is difficult to follow all the strands.
Morning Paul:
Here is an attempt to pull a few string together.
There appear to be two primary threads of though/discussion.
Here is a somewhat "normalised" version of the direction/scope of
discussions as I see them (so please jump in and correct me if
I'm missing anything dramatic). I'm assuming that we are all ok
with the Map type as opposed to Parameter, that there appears to
be a reasonable consensus that there are different concerns for
"service" managed versus "reference" managed components which
seem to be gravitating towards the ServiceManager and
ComponentManager respectively. I think its fair to say that the
ServiceManager is for all practical purposes stable as far as
principals are concerned. The ComponentManager discussion are
more recent and a will probably need another couple of laps
around the garden before everything is clear.
1. ServiceManager
- this is relatively stable relative to yesterdays
discussions
- last nights input raised the need for a parallel
hasXxxx operation that takes a Map as an additional
argument - paralleling lookup(String, Map )
semantics
interface ServiceManager
{
Object lookup( String role );
Object lookup( String role, Map policy );
boolean hasService( String role );
boolean hasService( String role, Map policy );
void release( Object key );
}
2. ComponentManager
- resurfacing of CM has been driven by what appears to be
separation of concerns between service decommissioning
as distinct from needs of referenced managed component
(hence the appearance of Object as token in the interface
below)
- this is being discussed as a complementary interface to
the ServiceManger described above
interface ComponentManager
{
Object lookup( Object token, String role );
Object lookup( Object token, String role, Map policy );
boolean hasComponent(Object role );
void release( Object component );
void releaseAll( Object token );
}
As Pete has frequently pointed out, I need to exercise my commit
muscles. As mentioned about - SM seems stable - CM appears to
need some fine tuning. I would like to go ahead and flex these new
found muscles by moving SM in the framework and committing the
Phoenix updates. However, being the almost newest committer on
the block I'll follow your lead.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen wrote :
><snip/> Maybe I'm
>being over-sensertive but I'm very aware of the fact that we are have
>already almost doubled the number of operations relative to CM - which
>leaves me with the question - can you do without it?
>
I could not agree more. Don't make me post that "What the user
wanted" cartoon again.
Can someone do a rollup of proposed alternative with pros and cons
please...... it is difficult to follow all the strands.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Antti Koivunen [mailto:anryoshi@users.sourceforge.net]
> Sent: Thursday, 14 February, 2002 06:45
> To: Avalon Developers List
> Subject: Re: [VOTE] RE: ComponentManager interface
>
>
> Stephen McConnell wrote:
> <skip/>
> >
> > interface ServiceManager
> > {
> > Object lookup( final String role );
> > Object lookup( final String role, Map policy );
> >
> > boolean hasService( final String role );
> > boolean hasService( final String role, Map policy ); <--
> addition ?
> >
> > void release( Object key );
> > }
> >
> > The addition of hasXxxxx( key, policy ) ensures that your not going
> > on a blind date.
>
> I agree, it's more consistent and required for something like:
>
> map.put("mime-type", "video/mpeg");
> boolean ok = sm.hasService(Codec.ROLE, map);
>
> There are many other cases where the policy/hint would just be a simple
> string. As the use of a Map has some performance implications, I might
> consider adding also:
>
> Object lookup( String role, String hint );
> boolean hasService( String role, String hint );
>
> The hint could be something simple, such as a mime-type, protocol or
> URL, but it would also allow the use of string queries, if necessary.
>
> What do you think?
Ummmm,... I'd like to avoid the additional methods if possible. The
fundamently attractive thing about the whole of the Avalon Framework
is this amazing combination of simplicity and functionality. Maybe I'm
being over-sensertive but I'm very aware of the fact that we are have
already almost doubled the number of operations relative to CM - which
leaves me with the question - can you do without it?
Cheers, Steve.
> (: A ;)
>
>
>
> --
> 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: [VOTE] RE: ComponentManager interface
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Stephen McConnell wrote:
<skip/>
>
> interface ServiceManager
> {
> Object lookup( final String role );
> Object lookup( final String role, Map policy );
>
> boolean hasService( final String role );
> boolean hasService( final String role, Map policy ); <-- addition ?
>
> void release( Object key );
> }
>
> The addition of hasXxxxx( key, policy ) ensures that your not going
> on a blind date.
I agree, it's more consistent and required for something like:
map.put("mime-type", "video/mpeg");
boolean ok = sm.hasService(Codec.ROLE, map);
There are many other cases where the policy/hint would just be a simple
string. As the use of a Map has some performance implications, I might
consider adding also:
Object lookup( String role, String hint );
boolean hasService( String role, String hint );
The hint could be something simple, such as a mime-type, protocol or
URL, but it would also allow the use of string queries, if necessary.
What do you think?
(: A ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] RE: ComponentManager interface
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi Steve, answer inline:
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Thursday, February 14, 2002 5:59 AM
>
>
> Paulo:
>
> I agree on the efficiency point, .. however the interface is
> loosing something in terms of implicit clarity and potential for
> consistent usage (it's starting to look more like hashtable
> get/indexof/remove).
Sorry Steve, I did not express my ideas that well on that post,
but maybe I did it a bit better on this one:
http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg06057.html
On the above linked post I give the example of a ClassicCM class
with a similar interface to the one you show here for the
ServiceManager (although with a "token" for easy component
release) that wraps a ComponentManager with an Object key.
I think that the ComponentManager and the ServiceManager have
more in common as a problem than they have different. And that
is my main concern - not the implementation efficiency (I was
not clear about this before).
IMO the ComponentManager and the ServiceManager are just
specializations of an ObjectManager (just to take the Component
and Service terms out of the way) that manages objects with a
LifeStyle (and a LifeCycle).
Of course that there can be several possible types of LifeStyles,
but an ObjectManager would specialize on knowing them and
managing such objects on an optimal way.
On top of that you could then build a specialization called
ComponentManager or ServiceManager to manage the specific types
of objects-with-a-LifeStyle that you call Components or
Services and for which you use a specific "indexing" strategy
(e.g.: role + parameters).
You could even manage other objects-with-a-LifeStyle... like
ScriptingVariables and strange things like that.
So, what I want to say is that I consider the problem of
managing objects-with-a-LifeStyle important enough to deserve
a separate layer. Then you could have
ObjectManagerImplementation
|
ObjectManager
(interface)
|
ComponentManagerWrapper
|
ComponentManager
(interface)
Meaning that you could have a specific implementation of an
ObjectManager interface which, using a ComponentManager
wrapper is exposed as a ComponentManager. The wrapper being
something like the ClassicCM class in
http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg06057.html
This means that you could easily replace the underlying
object management implementation with ease and even reuse
it for a ServiceManager like:
ObjectManagerImplementation
|
ObjectManager
(interface)
|
ServiceManagerWrapper
|
ServiceManager
(interface)
> I would prefer to move further towards an
> interface that (a) expresses notions of service provision/
> decommissioning more concretely and explicitly (i.e. closer to
> yesterday),
I think the above matches your concerns.
> but (b) enhanced to address input from yourself,
> Antti and Sylvain during the evening that touched on the
> parallelism between lookup and hasXxxx. Thinking about the
> parallelism issue for the last few hours as a result of those
> comments leads me to the conclusion that non-parallel
> lookup/hasXxxx effectively implies potentially unwarranted
> implementation restrictions. A resolution could be the addition
> of a supplementary hasXxxx method as shown below.
>
> interface ServiceManager
> {
> Object lookup( final String role );
> Object lookup( final String role, Map policy );
>
> boolean hasService( final String role );
> boolean hasService( final String role, Map policy ); <-- addition ?
>
> void release( Object key );
> }
>
> The addition of hasXxxxx( key, policy ) ensures that your not going
> on a blind date. The boolean result of the operation should
> semantically be quite clear in that TRUE hasXxxxx response should
> indicate that within reasonable operating conditions, the lookup
> operation will not fail. It is then up to implementations to resolve
> decisions concerning ability to honour a service availability
> commitment (potentially in the context supplied policy).
I agree, of course.
> What do you think?
>
> Cheers, Steve.
Have fun,
Paulo Gaspar
>
> > > ...but Map does allow potentially more efficient implementations.
> >
> > For efficiency:
> >
> > interface ServiceManager
> > {
> > Object lookup( Object key );
> > boolean hasService( Object key );
> > void release( Object key );
> > }
> >
> > IMO this provides the most efficient basic implementation and
> > maximum flexibility.
> >
> > Than you can specialize according to your needs.
> >
> >
> > Have fun,
> > Paulo Gaspar
> >
..........
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
Paulo:
I agree on the efficiency point, .. however the interface is
loosing something in terms of implicit clarity and potential for
consistent usage (it's starting to look more like hashtable
get/indexof/remove). I would prefer to move further towards an
interface that (a) expresses notions of service provision/
decommissioning more concretely and explicitly (i.e. closer to
yesterday), but (b) enhanced to address input from yourself,
Antti and Sylvain during the evening that touched on the
parallelism between lookup and hasXxxx. Thinking about the
parallelism issue for the last few hours as a result of those
comments leads me to the conclusion that non-parallel
lookup/hasXxxx effectively implies potentially unwarranted
implementation restrictions. A resolution could be the addition
of a supplementary hasXxxx method as shown below.
interface ServiceManager
{
Object lookup( final String role );
Object lookup( final String role, Map policy );
boolean hasService( final String role );
boolean hasService( final String role, Map policy ); <-- addition ?
void release( Object key );
}
The addition of hasXxxxx( key, policy ) ensures that your not going
on a blind date. The boolean result of the operation should
semantically be quite clear in that TRUE hasXxxxx response should
indicate that within reasonable operating conditions, the lookup
operation will not fail. It is then up to implementations to resolve
decisions concerning ability to honour a service availability
commitment (potentially in the context supplied policy).
What do you think?
Cheers, Steve.
> > ...but Map does allow potentially more efficient implementations.
>
> For efficiency:
>
> interface ServiceManager
> {
> Object lookup( Object key );
> boolean hasService( Object key );
> void release( Object key );
> }
>
> IMO this provides the most efficient basic implementation and
> maximum flexibility.
>
> Than you can specialize according to your needs.
>
>
> Have fun,
> Paulo Gaspar
>
> > -----Original Message-----
> > From: Antti Koivunen [mailto:anryoshi@users.sourceforge.net]
> > Sent: Wednesday, February 13, 2002 10:04 PM
> > To: Avalon Developers List
> > Subject: Re: [VOTE] RE: ComponentManager interface
> >
> >
> >
> > Stephen McConnell wrote:
> > > I understand and support the concern re. mixing in the Parameter
> > > object. Personally I would prefer Map over Query. Here is my
> > > understanding of what the interface would look like (all method
> > > included) based on quasi "consensus" at this stage + your
> > > suggested replacement of Parameters with Map.
> > >
> > > interface ServiceManager
> > > {
> > > Object lookup( final String role );
> > > Object lookup( final String role, final Map attributes );
> > > boolean hasObject( final String role );
> > > void release( Object object );
> > > }
> > >
> > > Is this ok with everyone?
> >
> > I can't vote, but it looks fine to me. For what it's worth, Parameters
> > would allow us to define the needed component with a single
> string, e.g.
> > "com.mycompany.MyComponent:myParam=value,yourParam=42", but Map does
> > allow potentially more efficient implementations.
> >
> > (: Anrie ;)
> > --
> > Antti Koivunen | "Anrie" [un-ree] <an...@users.sf.net>
> > ---------------------------------------------------------
> > The song of life might not be a simple one,
> > but there's plenty of room for improvisation.
> > ---------------------------------------------------------
> >
> >
> >
> > --
> > 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: [VOTE] RE: ComponentManager interface
Posted by Paulo Gaspar <pa...@krankikom.de>.
> ...but Map does allow potentially more efficient implementations.
For efficiency:
interface ServiceManager
{
Object lookup( Object key );
boolean hasService( Object key );
void release( Object key );
}
IMO this provides the most efficient basic implementation and
maximum flexibility.
Than you can specialize according to your needs.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Antti Koivunen [mailto:anryoshi@users.sourceforge.net]
> Sent: Wednesday, February 13, 2002 10:04 PM
> To: Avalon Developers List
> Subject: Re: [VOTE] RE: ComponentManager interface
>
>
>
> Stephen McConnell wrote:
> > I understand and support the concern re. mixing in the Parameter
> > object. Personally I would prefer Map over Query. Here is my
> > understanding of what the interface would look like (all method
> > included) based on quasi "consensus" at this stage + your
> > suggested replacement of Parameters with Map.
> >
> > interface ServiceManager
> > {
> > Object lookup( final String role );
> > Object lookup( final String role, final Map attributes );
> > boolean hasObject( final String role );
> > void release( Object object );
> > }
> >
> > Is this ok with everyone?
>
> I can't vote, but it looks fine to me. For what it's worth, Parameters
> would allow us to define the needed component with a single string, e.g.
> "com.mycompany.MyComponent:myParam=value,yourParam=42", but Map does
> allow potentially more efficient implementations.
>
> (: Anrie ;)
> --
> Antti Koivunen | "Anrie" [un-ree] <an...@users.sf.net>
> ---------------------------------------------------------
> The song of life might not be a simple one,
> but there's plenty of room for improvisation.
> ---------------------------------------------------------
>
>
>
> --
> 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: [VOTE] RE: ComponentManager interface
Posted by Antti Koivunen <an...@users.sourceforge.net>.
Stephen McConnell wrote:
> I understand and support the concern re. mixing in the Parameter
> object. Personally I would prefer Map over Query. Here is my
> understanding of what the interface would look like (all method
> included) based on quasi "consensus" at this stage + your
> suggested replacement of Parameters with Map.
>
> interface ServiceManager
> {
> Object lookup( final String role );
> Object lookup( final String role, final Map attributes );
> boolean hasObject( final String role );
> void release( Object object );
> }
>
> Is this ok with everyone?
I can't vote, but it looks fine to me. For what it's worth, Parameters
would allow us to define the needed component with a single string, e.g.
"com.mycompany.MyComponent:myParam=value,yourParam=42", but Map does
allow potentially more efficient implementations.
(: Anrie ;)
--
Antti Koivunen | "Anrie" [un-ree] <an...@users.sf.net>
---------------------------------------------------------
The song of life might not be a simple one,
but there's plenty of room for improvisation.
---------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] RE: ComponentManager interface
Posted by Stephen McConnell <mc...@osm.net>.
> > Another alternative to the whole explicit Query object is the following:
> >
> > interface ServiceManager
> > {
> > Object lookup( String role );
> > Object lookup( String role, Parameters attributes );
> > void release( Object component );
> > }
>
> I would prefer not to couple the service package and the
> parameters pacakge.
> So I guess I would prefer a Query object or if thats not a go
> then use a Map
> object rather than a Parameters object.
Pete:
I understand and support the concern re. mixing in the Parameter
object. Personally I would prefer Map over Query. Here is my
understanding of what the interface would look like (all method
included) based on quasi "consensus" at this stage + your
suggested replacement of Parameters with Map.
interface ServiceManager
{
Object lookup( final String role );
Object lookup( final String role, final Map attributes );
boolean hasObject( final String role );
void release( Object object );
}
Is this ok with everyone?
Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
On Thu, 14 Feb 2002 03:16, Berin Loritsch wrote:
> 1) The ServiceManager stays as is with the change that the key lookup
> is an Object instead of String (String is common case, but allows
> for Query object enhancement later).
>
> 2) The ServiceManager has two methods: one String, and one Query object
>
>
> Due to all the feedback, the Query object would be simplified to one
> key and attributes.
either works for me.
> Another alternative to the whole explicit Query object is the following:
>
> interface ServiceManager
> {
> Object lookup( String role );
> Object lookup( String role, Parameters attributes );
> void release( Object component );
> }
I would prefer not to couple the service package and the parameters pacakge.
So I guess I would prefer a Query object or if thats not a go then use a Map
object rather than a Parameters object.
--
Cheers,
Pete
------------------------------------------------------------
I just got lost in thought... It was unfamiliar territory.
------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Thu, 14 Feb 2002 12:10, Paulo Gaspar wrote:
>
>>So, if for services you would always have (although I still do
>>not like these keys):
>>
>> interface ServiceManager
>> {
>> Object lookup( String role );
>> Object lookup( String role, Parameters attributes );
>> void release( Object component );
>> }
>>
>>for a ComponentManager you could have:
>>
>> interface ComponentManager
>> {
>> Object lookup( Object token, String role );
>> Object lookup( Object token, String role, Parameters attributes );
>> void release( Object component );
>> void releaseAll( Object token );
>> }
>>
>
> I like that distinction except I would remove ServiceManager.release() as it
> is no longer really needed?
No, the releaseb requirements never left. The main issues are with pooled
components. They have to be managed.
Honestly, I woule like to see release moved to the Token object myself.
--
"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: [VOTE] RE: ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
On Thu, 14 Feb 2002 12:10, Paulo Gaspar wrote:
> So, if for services you would always have (although I still do
> not like these keys):
>
> interface ServiceManager
> {
> Object lookup( String role );
> Object lookup( String role, Parameters attributes );
> void release( Object component );
> }
>
> for a ComponentManager you could have:
>
> interface ComponentManager
> {
> Object lookup( Object token, String role );
> Object lookup( Object token, String role, Parameters attributes );
> void release( Object component );
> void releaseAll( Object token );
> }
I like that distinction except I would remove ServiceManager.release() as it
is no longer really needed?
--
Cheers,
Pete
------------------------------------------------------------
I just got lost in thought... It was unfamiliar territory.
------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] RE: ComponentManager interface
Posted by Paulo Gaspar <pa...@krankikom.de>.
Since the ServiceManager has a release() method, I guess that
services might not be Thread Safe???
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> Sent: Thursday, February 14, 2002 2:11 AM
> To: Avalon Developers List
> Subject: RE: [VOTE] RE: ComponentManager interface
>
>
> > My observations of the current CM/CS is that in a perfect world,
> > we would only need the CM. However, due to the complexities of
> > the real...
>
> I think that one of the differences is when you start using a
> token to free resources, which does not make sense for a Service,
> assuming that a service is Thread Safe and you just get to use it.
>
> So, if for services you would always have (although I still do
> not like these keys):
>
> interface ServiceManager
> {
> Object lookup( String role );
> Object lookup( String role, Parameters attributes );
> void release( Object component );
> }
>
> for a ComponentManager you could have:
>
> interface ComponentManager
> {
> Object lookup( Object token, String role );
> Object lookup( Object token, String role, Parameters attributes );
> void release( Object component );
> void releaseAll( Object token );
> }
>
> Have fun,
> Paulo Gaspar
>
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Wednesday, February 13, 2002 5:17 PM
> > To: Avalon Developers List
> > Subject: Re: [VOTE] RE: ComponentManager interface
> >
> >
> > Stephen McConnell wrote:
> > > Berin:
> > >
> > > Paul's vote on the ComponentManager interface proposal brings
> > > the number of +1 votes to 3, sufficient to go ahead with the
> > > ServiceManager proposal. Your reply on the initial request for
> > > vote was somewhat unclear with respect your position. If I
> > > understand correctly, you stated that in principal you would
> > > be -1 on anything not linked to Avalon 5.0. As the proposal
> > > is not linked to Avalon 5.0, can you clarify for me if your
> > > message should be counted as a veto. If not, I'll go ahead
> > > a commit the proposed service package this afternoon.
> > >
> > > Cheers, Steve.
> >
> >
> > :/
> >
> > I thought you could tell due to the fact that I was presenting the
> > Resolver package as an alternative that I haven't moved to +1 yet.
> >
> > I want to eventually add in a Query object ability--so we have two
> > options.
> >
> > 1) The ServiceManager stays as is with the change that the key lookup
> > is an Object instead of String (String is common case, but allows
> > for Query object enhancement later).
> >
> > 2) The ServiceManager has two methods: one String, and one Query object
> >
> >
> > Due to all the feedback, the Query object would be simplified to one
> > key and attributes.
> >
> > Another alternative to the whole explicit Query object is the following:
> >
> > interface ServiceManager
> > {
> > Object lookup( String role );
> > Object lookup( String role, Parameters attributes );
> > void release( Object component );
> > }
> >
> > This way, we can reasonably handle default Lookup, and have no need for
> > the ComponentSelector equivalent.
> >
> > My observations of the current CM/CS is that in a perfect world,
> > we would only need the CM. However, due to the complexities of the real
> > world, we need to address a specific configuration of a Component. The
> > ComponentSelector was introduced to satisfy that goal. However it is
> > terribly clumsy to have to do two levels of lookup.
> >
> > Please post your thoughts.
> >
> > If we introduce this change, we won't be able to add the extra
> > functionality
> > later for the Query object.
> >
> >
> > --
> >
> > "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>
--
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: [VOTE] RE: ComponentManager interface
Posted by Paulo Gaspar <pa...@krankikom.de>.
> My observations of the current CM/CS is that in a perfect world,
> we would only need the CM. However, due to the complexities of
> the real...
I think that one of the differences is when you start using a
token to free resources, which does not make sense for a Service,
assuming that a service is Thread Safe and you just get to use it.
So, if for services you would always have (although I still do
not like these keys):
interface ServiceManager
{
Object lookup( String role );
Object lookup( String role, Parameters attributes );
void release( Object component );
}
for a ComponentManager you could have:
interface ComponentManager
{
Object lookup( Object token, String role );
Object lookup( Object token, String role, Parameters attributes );
void release( Object component );
void releaseAll( Object token );
}
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, February 13, 2002 5:17 PM
> To: Avalon Developers List
> Subject: Re: [VOTE] RE: ComponentManager interface
>
>
> Stephen McConnell wrote:
> > Berin:
> >
> > Paul's vote on the ComponentManager interface proposal brings
> > the number of +1 votes to 3, sufficient to go ahead with the
> > ServiceManager proposal. Your reply on the initial request for
> > vote was somewhat unclear with respect your position. If I
> > understand correctly, you stated that in principal you would
> > be -1 on anything not linked to Avalon 5.0. As the proposal
> > is not linked to Avalon 5.0, can you clarify for me if your
> > message should be counted as a veto. If not, I'll go ahead
> > a commit the proposed service package this afternoon.
> >
> > Cheers, Steve.
>
>
> :/
>
> I thought you could tell due to the fact that I was presenting the
> Resolver package as an alternative that I haven't moved to +1 yet.
>
> I want to eventually add in a Query object ability--so we have two
> options.
>
> 1) The ServiceManager stays as is with the change that the key lookup
> is an Object instead of String (String is common case, but allows
> for Query object enhancement later).
>
> 2) The ServiceManager has two methods: one String, and one Query object
>
>
> Due to all the feedback, the Query object would be simplified to one
> key and attributes.
>
> Another alternative to the whole explicit Query object is the following:
>
> interface ServiceManager
> {
> Object lookup( String role );
> Object lookup( String role, Parameters attributes );
> void release( Object component );
> }
>
> This way, we can reasonably handle default Lookup, and have no need for
> the ComponentSelector equivalent.
>
> My observations of the current CM/CS is that in a perfect world,
> we would only need the CM. However, due to the complexities of the real
> world, we need to address a specific configuration of a Component. The
> ComponentSelector was introduced to satisfy that goal. However it is
> terribly clumsy to have to do two levels of lookup.
>
> Please post your thoughts.
>
> If we introduce this change, we won't be able to add the extra
> functionality
> later for the Query object.
>
>
> --
>
> "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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, 13 February, 2002 18:00
> To: Avalon Developers List
> Subject: Re: [VOTE] RE: ComponentManager interface
>
>
> Stephen McConnell wrote:
> >
> >>-----Original Message-----
> >>From: Berin Loritsch [mailto:bloritsch@apache.org]
> >>Sent: Wednesday, 13 February, 2002 17:17
> >>To: Avalon Developers List
> >>Subject: Re: [VOTE] RE: ComponentManager interface
> >>
> >>
> >>Stephen McConnell wrote:
> >>
> >>>Berin:
> >>>
> >>>Paul's vote on the ComponentManager interface proposal brings
> >>>the number of +1 votes to 3, sufficient to go ahead with the
> >>>ServiceManager proposal. Your reply on the initial request for
> >>>vote was somewhat unclear with respect your position. If I
> >>>understand correctly, you stated that in principal you would
> >>>be -1 on anything not linked to Avalon 5.0. As the proposal
> >>>is not linked to Avalon 5.0, can you clarify for me if your
> >>>message should be counted as a veto. If not, I'll go ahead
> >>>a commit the proposed service package this afternoon.
> >>>
> >>>Cheers, Steve.
> >>>
> >>
>
> >>Another alternative to the whole explicit Query object is the following:
> >>
> >>interface ServiceManager
> >>{
> >> Object lookup( String role );
> >> Object lookup( String role, Parameters attributes );
> >> void release( Object component );
> >>}
> >>
> >
> > Of the above options I think the interface described immediately
> > above makes the most sense. Its consistent with the CM/SM model
> > and the DefaultServiceManager can basically ignore the Parameters
> > argument, however, it does provide the basis on which an
> > implementation can do some serious resolution.
> >
>
>
> If we like the above ServiceManager interface, then I am +1 on that
> interface. At this point I would not need the Query object as the
> Parameters/Role combo satisfies that need.
I'm happy.
+1
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>>-----Original Message-----
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>Sent: Wednesday, 13 February, 2002 17:17
>>To: Avalon Developers List
>>Subject: Re: [VOTE] RE: ComponentManager interface
>>
>>
>>Stephen McConnell wrote:
>>
>>>Berin:
>>>
>>>Paul's vote on the ComponentManager interface proposal brings
>>>the number of +1 votes to 3, sufficient to go ahead with the
>>>ServiceManager proposal. Your reply on the initial request for
>>>vote was somewhat unclear with respect your position. If I
>>>understand correctly, you stated that in principal you would
>>>be -1 on anything not linked to Avalon 5.0. As the proposal
>>>is not linked to Avalon 5.0, can you clarify for me if your
>>>message should be counted as a veto. If not, I'll go ahead
>>>a commit the proposed service package this afternoon.
>>>
>>>Cheers, Steve.
>>>
>>
>>Another alternative to the whole explicit Query object is the following:
>>
>>interface ServiceManager
>>{
>> Object lookup( String role );
>> Object lookup( String role, Parameters attributes );
>> void release( Object component );
>>}
>>
>
> Of the above options I think the interface described immediately
> above makes the most sense. Its consistent with the CM/SM model
> and the DefaultServiceManager can basically ignore the Parameters
> argument, however, it does provide the basis on which an
> implementation can do some serious resolution.
>
If we like the above ServiceManager interface, then I am +1 on that
interface. At this point I would not need the Query object as the
Parameters/Role combo satisfies that need.
--
"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: [VOTE] RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, 13 February, 2002 17:17
> To: Avalon Developers List
> Subject: Re: [VOTE] RE: ComponentManager interface
>
>
> Stephen McConnell wrote:
> > Berin:
> >
> > Paul's vote on the ComponentManager interface proposal brings
> > the number of +1 votes to 3, sufficient to go ahead with the
> > ServiceManager proposal. Your reply on the initial request for
> > vote was somewhat unclear with respect your position. If I
> > understand correctly, you stated that in principal you would
> > be -1 on anything not linked to Avalon 5.0. As the proposal
> > is not linked to Avalon 5.0, can you clarify for me if your
> > message should be counted as a veto. If not, I'll go ahead
> > a commit the proposed service package this afternoon.
> >
> > Cheers, Steve.
>
>
> :/
>
> I thought you could tell due to the fact that I was presenting the
> Resolver package as an alternative that I haven't moved to +1 yet.
:-)
I had a sneaking suspicion that maybe you weren't quite at a +1!
> I want to eventually add in a Query object ability--so we have two
> options.
>
> 1) The ServiceManager stays as is with the change that the key lookup
> is an Object instead of String (String is common case, but allows
> for Query object enhancement later).
>
> 2) The ServiceManager has two methods: one String, and one Query object
>
>
> Due to all the feedback, the Query object would be simplified to one
> key and attributes.
>
> Another alternative to the whole explicit Query object is the following:
>
> interface ServiceManager
> {
> Object lookup( String role );
> Object lookup( String role, Parameters attributes );
> void release( Object component );
> }
Of the above options I think the interface described immediately
above makes the most sense. Its consistent with the CM/SM model
and the DefaultServiceManager can basically ignore the Parameters
argument, however, it does provide the basis on which an
implementation can do some serious resolution.
> This way, we can reasonably handle default Lookup, and have no need for
> the ComponentSelector equivalent.
Agreed.
> My observations of the current CM/CS is that in a perfect world,
> we would only need the CM. However, due to the complexities of the real
> world, we need to address a specific configuration of a Component. The
> ComponentSelector was introduced to satisfy that goal. However it is
> terribly clumsy to have to do two levels of lookup.
>
> Please post your thoughts.
Using the above interface things remain open as to what so of object
is returned - so it would be posssible for the container to do quite
interesting things concerning service/component preparation in the
knowlege that lookups can be parameterised. So, yep, I like it.
> If we introduce this change, we won't be able to add the extra
> functionality later for the Query object.
However, you could do something like the following:
public class DefaultQuery extends Parameters implements Query
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Berin:
>
> Paul's vote on the ComponentManager interface proposal brings
> the number of +1 votes to 3, sufficient to go ahead with the
> ServiceManager proposal. Your reply on the initial request for
> vote was somewhat unclear with respect your position. If I
> understand correctly, you stated that in principal you would
> be -1 on anything not linked to Avalon 5.0. As the proposal
> is not linked to Avalon 5.0, can you clarify for me if your
> message should be counted as a veto. If not, I'll go ahead
> a commit the proposed service package this afternoon.
>
> Cheers, Steve.
:/
I thought you could tell due to the fact that I was presenting the
Resolver package as an alternative that I haven't moved to +1 yet.
I want to eventually add in a Query object ability--so we have two
options.
1) The ServiceManager stays as is with the change that the key lookup
is an Object instead of String (String is common case, but allows
for Query object enhancement later).
2) The ServiceManager has two methods: one String, and one Query object
Due to all the feedback, the Query object would be simplified to one
key and attributes.
Another alternative to the whole explicit Query object is the following:
interface ServiceManager
{
Object lookup( String role );
Object lookup( String role, Parameters attributes );
void release( Object component );
}
This way, we can reasonably handle default Lookup, and have no need for
the ComponentSelector equivalent.
My observations of the current CM/CS is that in a perfect world,
we would only need the CM. However, due to the complexities of the real
world, we need to address a specific configuration of a Component. The
ComponentSelector was introduced to satisfy that goal. However it is
terribly clumsy to have to do two levels of lookup.
Please post your thoughts.
If we introduce this change, we won't be able to add the extra functionality
later for the Query object.
--
"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: [VOTE] RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
Berin:
Paul's vote on the ComponentManager interface proposal brings
the number of +1 votes to 3, sufficient to go ahead with the
ServiceManager proposal. Your reply on the initial request for
vote was somewhat unclear with respect your position. If I
understand correctly, you stated that in principal you would
be -1 on anything not linked to Avalon 5.0. As the proposal
is not linked to Avalon 5.0, can you clarify for me if your
message should be counted as a veto. If not, I'll go ahead
a commit the proposed service package this afternoon.
Cheers, Steve.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Wednesday, 13 February, 2002 10:48
> To: Avalon Developers List
> Subject: Re: [VOTE] RE: ComponentManager interface
>
>
> >
> >
> >On Tue, 12 Feb 2002 02:41, Stephen McConnell wrote:
> >
> >>(A) Clone interface, implementation, and exception into a
> >> new package org.apache.avalon.framework.service
> >>
> >
> +1
>
> Given the cost of abolishing Component, this is now my preferred option.
>
> * It is simple to do
> * It fits in with timescales I am interested im
> * It builds on existing proven designs
>
> - 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: [VOTE] RE: ComponentManager interface
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>On Tue, 12 Feb 2002 02:41, Stephen McConnell wrote:
>
>>(A) Clone interface, implementation, and exception into a
>> new package org.apache.avalon.framework.service
>>
>
+1
Given the cost of abolishing Component, this is now my preferred option.
* It is simple to do
* It fits in with timescales I am interested im
* It builds on existing proven designs
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Peter Donald <pe...@apache.org>.
On Tue, 12 Feb 2002 02:41, Stephen McConnell wrote:
> (A) Clone interface, implementation, and exception into a
> new package org.apache.avalon.framework.service
+1
> (B) Clone interface, implementation, and exception into a
> new package and defer package, interface and
> implementation naming for further discussion.
+0
> (C) Clone interface, implementation, and exception under
> the existing framework/component package and defer
> interface and implementation naming for further
> discussion.
+/-0 pending discussion
--
Cheers,
Pete
-------------------------
All things considered,
insanity may be the only
reasonable alternative.
-------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Berin:
>
> See notes in-line.
>>Steve, I can't help but think you are rushing things. Check out
>>the proposal I have under Framework's src/proposal/resolver directory.
>>It has some interfaces and a package.html file that describes how to
>>use it.
>>
>
> The Resolver package in src/proposal/resolver is something new. I'm
> not proposing anything new - simply addressing a minor design issue that
> restricts the use of the Avalon component model in mainstream
> application.
Seemingly minor design changes can cause a ripple effect and make other
projects that depend on us mad. Consider the change to PriorityQueue from
handling Comparables to handling Objects (the original intention). Sam
and GUMP pointed out that this "seemingly" minor change caused issues in
other projects.
>>I think it deserves some serious consideration.
>>
>>I have always been an advocate of not rushing design solutions. You
>>always regret it later on. Something as foundational as a framework
>>*must* be very careful of how we go about introducing change.
>>
>
> The change proposed is to replace "Component" with "Object" in a revised
> ComponentManger. Component is an empty interface but the obligation for
> classes to implement that interface means that those objects cannot be
> treated as components in Avalon. For example, a industry standard ORB
> cannot (according to the current ComponentManager interface) be supplied
> as a service to the objects it manages because an industry standard
> ORB does not implement "Component". In fact in cannot - an ORB is a
> class with no interfaces - it is instantiated by the JVM based on system
> properties that declare an ORB implementation class name. So there is
> a dilemma - either I define a wrapper - ComponentHolder.getObject() - or,
> we address the real problem. The real problem is that ComponentManager
> forces objects to implement Component. The real solution is to lift that
> restriction. This is not changing the framework - it is solving a
> an unnecessary restriction that is limiting the application of the
> framework in real industrial applications.
I understand your delema, but what we are talking about is a fundamental
shift. It may be that for your purposes, JNDI would be a better fit than
the ComponentManager. Excalibur has a couple of implementations of JNDI
classes that should help you out.
We want to be able to remove the requirement for any marker interface,
but we also want to address deficiencies in the ComponentManager usage as well.
I am not in favor of band-aid fixes. period.
>>Which one of those options is to have an Avalon 5.0 revision and work
>>out our solutions there? That is the one I am +1 on, and I am strongly
>>-1 on anything else.
>>
>
> No problem there - but what I'm proposing isn't "working out a solution".
> This is taking something the works, that is clean, simple, and elegant,
> eliminating a small but significant restriction with minimal side-effect
> and getting on with the job of delivering some important services. In
> respect to an Avalon 5.0 revision - yes - that's the time and place for
> enhancing Avalon and working out things like enhancements to component
> management. But lets be very clear about this - I'm not proposing an
> enhancement now, I'm proposing the elimination of an unnecessary
> restriction.
It is still working out a solution. There are other deficiencies in the
CM approach that are not addressed by this solution. The first of which
is the ability to obtain a reference to a specific configuration of a
Component without going through the ComponentSelector step. The second of
which is the ability to release all Components with one call. All of
these things do need to be considered.
>>If the current solutions don't satisfy your needs, you have to use
>>proprietary extensions.
>>
>
> I've been using Avalon in anger for over a year. During that time I've
> developed workarounds to a number of restrictions. More recently I moving
> some of that work into Avalon under cornerstone apps. This is work that
> leverages the contributions of other open-source activities. While
> including workarounds in proprietary solutions is fine - it really sucks
> when your trying to put in place industry standard components (ORB, PSS,
> INS, OTS, ...) as pluggable Phoenix service and you are forced to add
> wrappers around "EVERYTHING" that does not implement the magic Avalon
> Component interface. This sucks so much and its so simple to fix.
Neither you or I know the full extent of what a seemingly simple change
will cause.
>>You may find out that the proprietary extension was truly beneficial,
>>
>
> The "truly beneficial proprietary extension" is a holder class. The
> benefit of the holder class is that people have to write more lines code
> wrapping and unwrapping objects just because the Avalon ComponentManger
> interface has this small but significant anomaly. You, I, and everyone
> else knows that this is not beneficial, adds extra unnecessary lines
> code wrapping and unwrapping non-Component components - is just plain
> silly.
Holder == Handler. I am working out the formalized approach to that in
Excalibur.
>>or you may find out it was a dead end.
>>
>
> The wrapping objects that don't implement Component is a dead-end.
True, but now er are faced with a change--and we want the change to be
the most correct.
>>The trial
>>and error stage will cause unstability in the core API, and I cannot abide
>>that at this stage of the game.
>>
>
> That an unfair comment. There is nothing "trial and error" about what is
> being proposed. We are simply address resolution of a minor technical issue
> that unreasonably restricts the application of Avalon interfaces and
> implementations on a broad spectrum of software applications. Do you
> really believe that what is being proposed is "error prone" - ? Please take
> another look at the existing Avalon ComponentManager, compare this with
> the sources in proposal/service and you will see that this is simply a clone
> with the single exception of the replacement of "Component" with "Object".
> This is a NOT A STABILITY question. There IS NO TRAIL AND ERROR.
And there are things that multiple people *don't* like about the interface.
Should we throw them to the curb? If we are going to introduce change, lets
get the best solution--not necessarily the easiest solution.
>>Consider the proposals in the Framework, and we can work on something that
>>is powerful, flexible, elegant, and robust.
>>
>
> Under the scope of Avalon 5 - yes. As a solution to the unnecessary
> restrictions in current Avalon component management - no. I'm not getting
> into discussions now about enhancements (not in this thread). I'm address
> resolution of a issue. Its an important issue because it effect the
> framework - its an important issue because it deals with the usability of
> Avalon beyond the Avalon community. It an important issue because it has
> a direct impact on other communities that are considering Avalon for more
> that just logging and configuration.
What you are proposing is technically an "enhancement", so its too late.
I understand all your points, so I say again, what are your oppinions on the
Resolver code? Would this elegantly handle your requirements while solving
the necessity of the ComponentSelector and easily releasing all Components
that are managed resources?
I mean, if we are going to introduce change, let's do it right.
--
"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: [VOTE] RE: ComponentManager interface
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen, Berin,
I agree that we should address the Object/Component issue in advance of
a rework of the framewor. I do not wish to detract from the importance
of careful planing for framework 5.0, but we have several compelling
reasons to have a lookup(..) feature that returns Object sooner than
that a rework could deliver.
It is a mod that can be made and settled without danger quite quickly.
To tie it up with a larger work of redesign would be a disaster to
those that need it now...
- Paul
>Berin:
>
>See notes in-line.
>
>>-----Original Message-----
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>Sent: Monday, 11 February, 2002 17:19
>>To: Avalon Developers List
>>Subject: Re: [VOTE] RE: ComponentManager interface
>>
>>
>>Stephen McConnell wrote:
>>
>>>This brings us down to options (3) and (4), both involving
>>>creation of quasi parallel interfaces and implementation
>>>of ComponentManger and DefaultComponentManager which deal
>>>with Object as distinct from Component.
>>>
>>>I've broken this down into three options which we can vote
>>>on, the first option is to go ahead with the proposed
>>>framework/service package. The second option is to go ahead
>>>but defer a decision on the package name pending further
>>>discussion, and the third option is to add a new interface and
>>>implementation to the current component package.
>>>
>>>(A) Clone interface, implementation, and exception into a
>>> new package org.apache.avalon.framework.service
>>>
>>>(B) Clone interface, implementation, and exception into a
>>> new package and defer package, interface and
>>> implementation naming for further discussion.
>>>
>>>(C) Clone interface, implementation, and exception under
>>> the existing framework/component package and defer
>>> interface and implementation naming for further
>>> discussion.
>>>
>>>To kick things off, here is my vote:
>>>
>>>(A) +1
>>>(B) +0,
>>>(C) -0
>>>
>>>Cheers, Steve.
>>>
>>
>>Steve, I can't help but think you are rushing things. Check out
>>the proposal I have under Framework's src/proposal/resolver directory.
>>It has some interfaces and a package.html file that describes how to
>>use it.
>>
>
>The Resolver package in src/proposal/resolver is something new. I'm
>not proposing anything new - simply addressing a minor design issue that
>restricts the use of the Avalon component model in mainstream
>application.
>
>>I think it deserves some serious consideration.
>>
>>I have always been an advocate of not rushing design solutions. You
>>always regret it later on. Something as foundational as a framework
>>*must* be very careful of how we go about introducing change.
>>
>
>The change proposed is to replace "Component" with "Object" in a revised
>ComponentManger. Component is an empty interface but the obligation for
>classes to implement that interface means that those objects cannot be
>treated as components in Avalon. For example, a industry standard ORB
>cannot (according to the current ComponentManager interface) be supplied
>as a service to the objects it manages because an industry standard
>ORB does not implement "Component". In fact in cannot - an ORB is a
>class with no interfaces - it is instantiated by the JVM based on system
>properties that declare an ORB implementation class name. So there is
>a dilemma - either I define a wrapper - ComponentHolder.getObject() - or,
>we address the real problem. The real problem is that ComponentManager
>forces objects to implement Component. The real solution is to lift that
>restriction. This is not changing the framework - it is solving a
>an unnecessary restriction that is limiting the application of the
>framework in real industrial applications.
>
>>Which one of those options is to have an Avalon 5.0 revision and work
>>out our solutions there? That is the one I am +1 on, and I am strongly
>>-1 on anything else.
>>
>
>No problem there - but what I'm proposing isn't "working out a solution".
>This is taking something the works, that is clean, simple, and elegant,
>eliminating a small but significant restriction with minimal side-effect
>and getting on with the job of delivering some important services. In
>respect to an Avalon 5.0 revision - yes - that's the time and place for
>enhancing Avalon and working out things like enhancements to component
>management. But lets be very clear about this - I'm not proposing an
>enhancement now, I'm proposing the elimination of an unnecessary
>restriction.
>
>>If the current solutions don't satisfy your needs, you have to use
>>proprietary extensions.
>>
>
>I've been using Avalon in anger for over a year. During that time I've
>developed workarounds to a number of restrictions. More recently I moving
>some of that work into Avalon under cornerstone apps. This is work that
>leverages the contributions of other open-source activities. While
>including workarounds in proprietary solutions is fine - it really sucks
>when your trying to put in place industry standard components (ORB, PSS,
>INS, OTS, ...) as pluggable Phoenix service and you are forced to add
>wrappers around "EVERYTHING" that does not implement the magic Avalon
>Component interface. This sucks so much and its so simple to fix.
>
>>You may find out that the proprietary extension was truly beneficial,
>>
>
>The "truly beneficial proprietary extension" is a holder class. The
>benefit of the holder class is that people have to write more lines code
>wrapping and unwrapping objects just because the Avalon ComponentManger
>interface has this small but significant anomaly. You, I, and everyone
>else knows that this is not beneficial, adds extra unnecessary lines
>code wrapping and unwrapping non-Component components - is just plain
>silly.
>
>>or you may find out it was a dead end.
>>
>
>The wrapping objects that don't implement Component is a dead-end.
>
>>The trial
>>and error stage will cause unstability in the core API, and I cannot abide
>>that at this stage of the game.
>>
>
>That an unfair comment. There is nothing "trial and error" about what is
>being proposed. We are simply address resolution of a minor technical issue
>that unreasonably restricts the application of Avalon interfaces and
>implementations on a broad spectrum of software applications. Do you
>really believe that what is being proposed is "error prone" - ? Please take
>another look at the existing Avalon ComponentManager, compare this with
>the sources in proposal/service and you will see that this is simply a clone
>with the single exception of the replacement of "Component" with "Object".
>This is a NOT A STABILITY question. There IS NO TRAIL AND ERROR.
>
>>Consider the proposals in the Framework, and we can work on something that
>>is powerful, flexible, elegant, and robust.
>>
>
>Under the scope of Avalon 5 - yes. As a solution to the unnecessary
>restrictions in current Avalon component management - no. I'm not getting
>into discussions now about enhancements (not in this thread). I'm address
>resolution of a issue. Its an important issue because it effect the
>framework - its an important issue because it deals with the usability of
>Avalon beyond the Avalon community. It an important issue because it has
>a direct impact on other communities that are considering Avalon for more
>that just logging and configuration.
>
>Cheers, Steve.
>
>
>
>
>--
>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: [VOTE] RE: ComponentManager interface
Posted by Stephen McConnell <mc...@apache.org>.
Berin:
See notes in-line.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Monday, 11 February, 2002 17:19
> To: Avalon Developers List
> Subject: Re: [VOTE] RE: ComponentManager interface
>
>
> Stephen McConnell wrote:
> > This brings us down to options (3) and (4), both involving
> > creation of quasi parallel interfaces and implementation
> > of ComponentManger and DefaultComponentManager which deal
> > with Object as distinct from Component.
> >
> > I've broken this down into three options which we can vote
> > on, the first option is to go ahead with the proposed
> > framework/service package. The second option is to go ahead
> > but defer a decision on the package name pending further
> > discussion, and the third option is to add a new interface and
> > implementation to the current component package.
> >
> > (A) Clone interface, implementation, and exception into a
> > new package org.apache.avalon.framework.service
> >
> > (B) Clone interface, implementation, and exception into a
> > new package and defer package, interface and
> > implementation naming for further discussion.
> >
> > (C) Clone interface, implementation, and exception under
> > the existing framework/component package and defer
> > interface and implementation naming for further
> > discussion.
> >
> > To kick things off, here is my vote:
> >
> > (A) +1
> > (B) +0,
> > (C) -0
> >
> > Cheers, Steve.
>
>
> Steve, I can't help but think you are rushing things. Check out
> the proposal I have under Framework's src/proposal/resolver directory.
> It has some interfaces and a package.html file that describes how to
> use it.
The Resolver package in src/proposal/resolver is something new. I'm
not proposing anything new - simply addressing a minor design issue that
restricts the use of the Avalon component model in mainstream
application.
> I think it deserves some serious consideration.
>
> I have always been an advocate of not rushing design solutions. You
> always regret it later on. Something as foundational as a framework
> *must* be very careful of how we go about introducing change.
The change proposed is to replace "Component" with "Object" in a revised
ComponentManger. Component is an empty interface but the obligation for
classes to implement that interface means that those objects cannot be
treated as components in Avalon. For example, a industry standard ORB
cannot (according to the current ComponentManager interface) be supplied
as a service to the objects it manages because an industry standard
ORB does not implement "Component". In fact in cannot - an ORB is a
class with no interfaces - it is instantiated by the JVM based on system
properties that declare an ORB implementation class name. So there is
a dilemma - either I define a wrapper - ComponentHolder.getObject() - or,
we address the real problem. The real problem is that ComponentManager
forces objects to implement Component. The real solution is to lift that
restriction. This is not changing the framework - it is solving a
an unnecessary restriction that is limiting the application of the
framework in real industrial applications.
> Which one of those options is to have an Avalon 5.0 revision and work
> out our solutions there? That is the one I am +1 on, and I am strongly
> -1 on anything else.
No problem there - but what I'm proposing isn't "working out a solution".
This is taking something the works, that is clean, simple, and elegant,
eliminating a small but significant restriction with minimal side-effect
and getting on with the job of delivering some important services. In
respect to an Avalon 5.0 revision - yes - that's the time and place for
enhancing Avalon and working out things like enhancements to component
management. But lets be very clear about this - I'm not proposing an
enhancement now, I'm proposing the elimination of an unnecessary
restriction.
> If the current solutions don't satisfy your needs, you have to use
> proprietary extensions.
I've been using Avalon in anger for over a year. During that time I've
developed workarounds to a number of restrictions. More recently I moving
some of that work into Avalon under cornerstone apps. This is work that
leverages the contributions of other open-source activities. While
including workarounds in proprietary solutions is fine - it really sucks
when your trying to put in place industry standard components (ORB, PSS,
INS, OTS, ...) as pluggable Phoenix service and you are forced to add
wrappers around "EVERYTHING" that does not implement the magic Avalon
Component interface. This sucks so much and its so simple to fix.
> You may find out that the proprietary extension was truly beneficial,
The "truly beneficial proprietary extension" is a holder class. The
benefit of the holder class is that people have to write more lines code
wrapping and unwrapping objects just because the Avalon ComponentManger
interface has this small but significant anomaly. You, I, and everyone
else knows that this is not beneficial, adds extra unnecessary lines
code wrapping and unwrapping non-Component components - is just plain
silly.
> or you may find out it was a dead end.
The wrapping objects that don't implement Component is a dead-end.
> The trial
> and error stage will cause unstability in the core API, and I cannot abide
> that at this stage of the game.
That an unfair comment. There is nothing "trial and error" about what is
being proposed. We are simply address resolution of a minor technical issue
that unreasonably restricts the application of Avalon interfaces and
implementations on a broad spectrum of software applications. Do you
really believe that what is being proposed is "error prone" - ? Please take
another look at the existing Avalon ComponentManager, compare this with
the sources in proposal/service and you will see that this is simply a clone
with the single exception of the replacement of "Component" with "Object".
This is a NOT A STABILITY question. There IS NO TRAIL AND ERROR.
> Consider the proposals in the Framework, and we can work on something that
> is powerful, flexible, elegant, and robust.
Under the scope of Avalon 5 - yes. As a solution to the unnecessary
restrictions in current Avalon component management - no. I'm not getting
into discussions now about enhancements (not in this thread). I'm address
resolution of a issue. Its an important issue because it effect the
framework - its an important issue because it deals with the usability of
Avalon beyond the Avalon community. It an important issue because it has
a direct impact on other communities that are considering Avalon for more
that just logging and configuration.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] RE: ComponentManager interface
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> This brings us down to options (3) and (4), both involving
> creation of quasi parallel interfaces and implementation
> of ComponentManger and DefaultComponentManager which deal
> with Object as distinct from Component.
>
> I've broken this down into three options which we can vote
> on, the first option is to go ahead with the proposed
> framework/service package. The second option is to go ahead
> but defer a decision on the package name pending further
> discussion, and the third option is to add a new interface and
> implementation to the current component package.
>
> (A) Clone interface, implementation, and exception into a
> new package org.apache.avalon.framework.service
>
> (B) Clone interface, implementation, and exception into a
> new package and defer package, interface and
> implementation naming for further discussion.
>
> (C) Clone interface, implementation, and exception under
> the existing framework/component package and defer
> interface and implementation naming for further
> discussion.
>
> To kick things off, here is my vote:
>
> (A) +1
> (B) +0,
> (C) -0
>
> Cheers, Steve.
Steve, I can't help but think you are rushing things. Check out
the proposal I have under Framework's src/proposal/resolver directory.
It has some interfaces and a package.html file that describes how to
use it.
I think it deserves some serious consideration.
I have always been an advocate of not rushing design solutions. You
always regret it later on. Something as foundational as a framework
*must* be very careful of how we go about introducing change.
Which one of those options is to have an Avalon 5.0 revision and work
out our solutions there? That is the one I am +1 on, and I am strongly
-1 on anything else.
If the current solutions don't satisfy your needs, you have to use
proprietary extensions. You may find out that the proprietary extension
was truly beneficial, or you may find out it was a dead end. The trial
and error stage will cause unstability in the core API, and I cannot abide
that at this stage of the game.
Consider the proposals in the Framework, and we can work on something that
is powerful, flexible, elegant, and robust.
--
"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: [VOTE] RE: ComponentManager interface
Posted by Gerhard Froehlich <g-...@gmx.de>.
Ok guys,
I struggled now a long time with myself. Nevertheless I don't
like the approach which was choosen here. I can bet the
solution (A), (B) and (C) will deprecate in the 5.0 release.
I could beat myself with GenericComponentManager proposal. Hmm
ja ambivalent.
It's not the solution, it's the way how it's integrated
which I don't like.
(I was one those, who were naged by GUMP a long time, because
the return values from the PriorityQueue was changed from
Comparable to Object)
>(A) Clone interface, implementation, and exception into a
> new package org.apache.avalon.framework.service
-0
>(B) Clone interface, implementation, and exception into a
> new package and defer package, interface and
> implementation naming for further discussion.
-0
>(C) Clone interface, implementation, and exception under
> the existing framework/component package and defer
> interface and implementation naming for further
> discussion.
-0
Consider:
"Gut Ding braucht Weile" == "Rome wasn't built in a day"
~Gerhard
"Anything awful makes me laugh.
I misbehaved once at a funeral..."
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>