avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Resolver package--Please post your thoughts
Date Wed, 13 Feb 2002 14:27:44 GMT
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
>>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.



"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message