On Thu, 13 Mar 2003 00:28, Jason van Zyl wrote:
> So marker interfaces like ThreadSafe? So handlers will be specified via
> configuration like in Fortress with the specification of a handler?
If such concepts exist then they will be specified by metadata of some sort.
Could be like fortress with per assembly metadata or like Phoenix with per
component metadata.
The last six months I have been developing a container that extracts all
metadata from attributes/javadoc tags (similar to commons-attributes, dot.net
attributes or the various interceptor frameworks). So it would end up being
specified by something like
/**
* @fortress.lifecycle name="ThreadSafe"
*/
public class MyComponent {}
> If the Selector interfaces are going to be deprecated what will replace
> them?
For Selectors that take strings then hopefully
lookup( Blah.ROLE + "/Selector" ).get( "foo" );
will be replaced by
lookup( Blah.ROLE + "/foo" );
For non string based selectors they should be implemented as specific
"Manager" objects like.
interface BlahManager
{
Blah getManager(....);
void releaseManager(Manager);
}
> Just curious as I want to keep Plexus current. We added Selector goodies
> in not knowing they would be deprecated along with a default selector
> mechanism. How will one grab a specific implementation among many now?
Hopefully array and map dependencies will also be more widely adopted. ie
(Blah[])lookup( Blah.ROLE + "[]" );
(Map)lookup( Blah.ROLE + "{}" ); //returns a map of name to service
--
Cheers,
Peter Donald
------------------------------------------------
| We shall not cease from exploration, and the |
| end of all our exploring will be to arrive |
| where we started and know the place for the |
| first time -- T.S. Eliot |
------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
