You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2002/12/07 21:03:58 UTC
Locators (was: Re: Context: usage recommendations?)
Stephen wrote:
> * Service locator
>
> This is a new concept that is very similar to the
> Merlin extension handler. It a component that provides
> a plug-in lookup solution that can be narrowed to a
> particular interface (and can be located by the container
> using the interface name as the key). A service locator
> can be applied to the following three areas:
>
> * context value lookup
> * service lookup
> * lifecycle stage handler lookup
If you have two interfaces:
interface A {
void method ();
}
interface B {
void method ();
}
and a dynamic proxy (or any class) implementing both interfaces:
class Proxy implements A, B {
...
}
Proxy proxy = ...;
The two calls:
((A) proxy).method ();
((B) proxy).method ();
are indistiguishable. This is true even if you are using a dynamic proxy's
InvocationHandler. (In which case they will both be calls to A.method.)
Unlike C#, Java has no way of distinguishing through what interface the
call was made.
I think this makes your idea less useful.
(Yes, I have a proposal of my own, writing it right now...)
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Locators (was: Re: Context: usage recommendations?)
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
> Stephen wrote:
> > * Service locator
> >
> > This is a new concept that is very similar to the
> > Merlin extension handler. It a component that provides
> > a plug-in lookup solution that can be narrowed to a
> > particular interface (and can be located by the container
> > using the interface name as the key). A service locator
> > can be applied to the following three areas:
> >
> > * context value lookup
> > * service lookup
> > * lifecycle stage handler lookup
>
> If you have two interfaces:
>
> interface A {
> void method ();
> }
>
> interface B {
> void method ();
> }
>
> and a dynamic proxy (or any class) implementing both interfaces:
>
> class Proxy implements A, B {
> ...
> }
>
> Proxy proxy = ...;
>
> The two calls:
>
> ((A) proxy).method ();
> ((B) proxy).method ();
>
> are indistiguishable. This is true even if you are using a dynamic
> proxy's
> InvocationHandler. (In which case they will both be calls to A.method.)
>
> Unlike C#, Java has no way of distinguishing through what interface the
> call was made.
>
> I think this makes your idea less useful.
It is a restriction that can be detected at build time. Assume that you
have meta data associated with a locator, you can assess conflicts at
two levels: (a) interface conflicts, and (b) duplicate key conflicts.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Locators (was: Re: Context: usage recommendations?)
Posted by Adam Murdoch <ad...@apache.org>.
On Sun, 8 Dec 2002 08:22 pm, Stephen McConnell wrote:
> Ok, I'm confussed - have the impression that we are talking about two
> different things.
We were. I missed the fact that you were casting to a locator, not directly
to a service. So you can ignore my comments :)
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Locators (was: Re: Context: usage recommendations?)
Posted by Stephen McConnell <mc...@apache.org>.
Adam Murdoch wrote:
>Several more problems with the narrowing approach:
>
>- Forces the container to use a proxy of some kind, regardless of whether the
>container needs to isolate components. Limits the container's options for
>scaling down.
>
The proxy case is only required if:
(a) your mapping in multiple interfaces
(b) your handling backward compatability
I.e. its the component author that is forcing the use of proxies for
particular use cases, not the container.
>
>
>- Prevents the use of the same interface for multiple services (including
>super-interfaces).
>
Only if your aggregating interfaces as opposed to definting a single
locator that supports one interface derived from another interface. For
example, a PhoenixBlockContext could extend AvalonStandardContext. This
has impact at the meta level but its a workable proposition then enables
interface reuse.
>
>- Prevents delivery of things that are not interfaces (eg File or
>ClassLoader).
>
I don't think this is an issue - the object that is proxied is the
aurgument to contextualize or service. Things like File and ClassLoader
are then accessed via get, or locate, or getWorkingDirectory, etc.
>
>
>- Prevents additional services from being added during the lifetime of the
>component.
>
Disagee - the notion of wether something is dynamic or not should not be
prevented by the existance of the proxy. Remember that the dynamic
service access is invoked against the proxy - the proxy is not the
service your requesting.
>
>- Limits lookup and query mechanisms to cast and instanceof. Prevents us
>adding additional kinds of lookup and query methods later.
>
Ok, I'm confussed - have the impression that we are talking about two
different things.
Consider the non-proxy core case:
public void service( Locator locator )
{
Object object = locator.locate( "my-key" );
}
Consider the non-proxy typed case:
public void service( Locator locator )
{
MyLocator manager = (MyLocator) locator;
Object object = manager.getSomeObject();
}
Consider the non-proxy Context/ComponentManager/ServiceManager wrapper
ServiceManager manager = new MappedServiceManager();
try
{
manager.put( locator );
manager.put( myService );
manager.put( anotherLocator )
}
catch( DuplicateKeyException )
{
// do something
}
((Serviceable)object).service( manager );
The complex case is where your aggegating a set of locators and your
using a proxy to convert this into a single obect that can be narrow to
diferent types. That scenario raises the potential for method conflict
- but that a build time concern, not a runtime concern.
Cheers, Steve.
>
>On Sun, 8 Dec 2002 06:03 am, Leo Sutic wrote:
>
>>Stephen wrote:
>> > * Service locator
>> >
>> > This is a new concept that is very similar to the
>> > Merlin extension handler. It a component that provides
>> > a plug-in lookup solution that can be narrowed to a
>> > particular interface (and can be located by the container
>> > using the interface name as the key). A service locator
>> > can be applied to the following three areas:
>> >
>> > * context value lookup
>> > * service lookup
>> > * lifecycle stage handler lookup
>>
>>If you have two interfaces:
>>
>>interface A {
>> void method ();
>>}
>>
>>interface B {
>> void method ();
>>}
>>
>>and a dynamic proxy (or any class) implementing both interfaces:
>>
>>class Proxy implements A, B {
>> ...
>>}
>>
>>Proxy proxy = ...;
>>
>>The two calls:
>>
>>((A) proxy).method ();
>>((B) proxy).method ();
>>
>>are indistiguishable. This is true even if you are using a dynamic proxy's
>>InvocationHandler. (In which case they will both be calls to A.method.)
>>
>>Unlike C#, Java has no way of distinguishing through what interface the
>>call was made.
>>
>>I think this makes your idea less useful.
>>
>>(Yes, I have a proposal of my own, writing it right now...)
>>
>>/LS
>>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Locators (was: Re: Context: usage recommendations?)
Posted by Adam Murdoch <ad...@apache.org>.
Several more problems with the narrowing approach:
- Forces the container to use a proxy of some kind, regardless of whether the
container needs to isolate components. Limits the container's options for
scaling down.
- Prevents the use of the same interface for multiple services (including
super-interfaces).
- Prevents delivery of things that are not interfaces (eg File or
ClassLoader).
- Prevents additional services from being added during the lifetime of the
component.
- Limits lookup and query mechanisms to cast and instanceof. Prevents us
adding additional kinds of lookup and query methods later.
On Sun, 8 Dec 2002 06:03 am, Leo Sutic wrote:
> Stephen wrote:
> > * Service locator
> >
> > This is a new concept that is very similar to the
> > Merlin extension handler. It a component that provides
> > a plug-in lookup solution that can be narrowed to a
> > particular interface (and can be located by the container
> > using the interface name as the key). A service locator
> > can be applied to the following three areas:
> >
> > * context value lookup
> > * service lookup
> > * lifecycle stage handler lookup
>
> If you have two interfaces:
>
> interface A {
> void method ();
> }
>
> interface B {
> void method ();
> }
>
> and a dynamic proxy (or any class) implementing both interfaces:
>
> class Proxy implements A, B {
> ...
> }
>
> Proxy proxy = ...;
>
> The two calls:
>
> ((A) proxy).method ();
> ((B) proxy).method ();
>
> are indistiguishable. This is true even if you are using a dynamic proxy's
> InvocationHandler. (In which case they will both be calls to A.method.)
>
> Unlike C#, Java has no way of distinguishing through what interface the
> call was made.
>
> I think this makes your idea less useful.
>
> (Yes, I have a proposal of my own, writing it right now...)
>
> /LS
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>