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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
