Gerhard Froehlich wrote:
> Berin,
> see dumb question inline:
>
>
>>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.
>>
>>Please either take the approach of fine-tuning the interfaces or of providing an
>alternative.
>>It also helps when you state the reasons why you beleive your alternative is better
>:)
>>
>>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).
>>
>>It also means that we should do the following:
>>
>>* Promote ComponentHandler interface and implementations to Framework
>>
>
> This is the "Manager", who handles the Resolver request, or?
This is the policy by which a Component's lifestyle is managed. IOW, if A component
must be pooled, or should have one instance per thread.
>>* Provide standard mechanism for registering a Component with a handler
>> - ComponentInfo? (like BlockInfo)
>> - Manifest entries?
>> - Other?
>>
>
> What does this "registering with a handler" exactly mean? Does it just replaces
> the Component marker interface, or do you intend to replace all interfaces -like
> Configurable- with that? If yes, do you have a idea how we can implement this?
The ComponentHandler manages the lifestyle--we need a way of associating the
ComponentHandler with the Component implementation without using marker interfaces.
>>* Finalize Resolver framework, or whatever the replacement ends up being
>>
>>If this seems like a winning migration path, and we really like this approach, we
>can make
>>it a part of Framework 4.2 or something like that. It is important that we have
>working
>>implementations though.
>>
>
> Towards a complete re-factoring of the *whole* framework, it's surly a method of
>resolution.
> But maybe we should look at the *things* standard Java can serve us, too (just to
>prevent
> to re-invent the wheel twice). Especially the lookup of the objects.
Ok.
--
"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]>
