Peter Donald wrote:
> On Wed, 13 Feb 2002 05:42, Berin Loritsch wrote:
>
>>I have tried to address all the shortcommings of the
>>ComponentManager/ComponentSelector approach in the Resolver package.
>>(located in Avalon Framework src/proposals directory). If you find that
>>this package does *not* support your needs, or appears clumsy/difficult to
>>use, please air your grievances now.
>>
>
> will do ;)
>
> Waaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaay too complex. The reason
> for CM to initially exist was that it was a much simpler interface than any
> of the other naming/directory APIs. I would much prefer to use an existing
> standard API (ie JNDI) than this because the standard while a little complex
> is standard and much easier for new develoeprs to adopt.
>
> This is not simple. Initially when you were taslking about this I thought it
> would be something as simple as
>
> interface ComponentManager
> {
> Object lookup(String role);
> Object lookup(Query query);
> }
>
> class Query
> {
> Query(String role) {}
> void addAttribute( String name, String value );
> }
>
> Such that
>
> lookup( MyService.ROLE ) is equivelent to lookup( new Query(MyService.ROLE) )
And we can go back to this. As I put it together, I realized that it would
be *possible* to obtain the reference to multiple objects at with one call.
It can be more efficient, and support cleaner client code. (Something that
JNDI cannot boast).
My thinking behind the Token is to allow a single release point for all components
attached to it, thus making the finally clause simpler.
> If you wanted other attributes to use in lookup you would use something like
>
> query = new Query(MyService.ROLE);
> query.setAttribute( "timeToLive", "3" );
> lookup( query )
>
> This I think is acceptable because in most cases the users will never need to
> use the more complex construction but if they have to they can.
True. We can do that (That is what discussion is for).
>>Since everyone is keen on removing the necessity of marker interfaces
>>sooner than later, I want a smooth migration path. That means that we need
>>a replacement for Component resolution (without the Component interface).
>>
>
> I am all for the minimal change as possible - basically the ServiceManager
> stuff the Stephen proposed.
>
>
>>It also means that we should do the following:
>>
>>* Promote ComponentHandler interface and implementations to Framework
>>
>
> -1 - a concern of the container
Not necessarily. It is a concern of the Component Developer. A Container
cannot divine that the Component Developer intended when he created the
Component. We had marker interfaces that provided hints--but this is a
tenuous contract.
We *need* a way to specify how a Container should handle the Component
instances. If a Component is not Threadsafe--which a large number aren't--
we need to specify a policy for them. Many components can be instantiated
one per thread, but still others must be fully pooled so that a unique
instance is returned *per*request*.
If we are going to remove lifestyle interfaces, we must have a replacement
mechanism. This mechanism is simple and workable.
>>* Provide standard mechanism for registering a Component with a handler
>> - ComponentInfo? (like BlockInfo)
>> - Manifest entries?
>> - Other?
>>
>
> -1 - a concern of the container
Again, I disagree. See above.
> While I would like to see a basic container that leveraged existing designs -
> I don't think it should be in framework that this is done - at least not
> until it is thouroughly specced out and very mature. Keep it in excalibur
> toill then.
The Container will remain there as long as necessary. I am talking about
the ComponentHandler interface, and a mechanism for the Component developer
to associate their Component with a Handler that will perform correctly for
it.
If there are N different containers, each with their own unique association
strategy, then we have N different association strategies. The Component
developer will be driven mad!
This is not good.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
