avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <adammurd...@apache.org>
Subject Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date Wed, 04 Dec 2002 00:07:45 GMT

[This is a kinda long, general response]

On Tue, 3 Dec 2002 11:00 pm, Peter Donald wrote:
> On Tue, 3 Dec 2002 23:38, Adam Murdoch wrote:
> > * If it turns out that both are beneficial, we have some more work ahead
> > of us, as neither Context nor ServiceManager reflect this.
>
> Both are beneficial. Useful elements from context;
>
> data:
>  - names (including component, partition and application)
>  - classloader(s)
>  - base deployment directory (potentially work directory aswell)
>
> services:
>  - access to input streams of resources stored in deployment package.
>  - access to proxying/interceptor chains for current block and ability
>    to construct new chains for objects you want to pass around
>  - access to "manager" element for current application or parts of current
>    application

These are useful things, no question.  Components need some way to get at data 
and services that are supplied by the container.  Again, why do they care 
that a particular service or piece of data was supplied by the container or a 
peer?  To put it in code terms, why is this:

public void contextualize( Context context )
{
    proxyFactory = (ProxyFactory)context.get( ProxyFactory.ROLE );
    // or, say, proxyFactory = (ProxyFactory)context;
}

public void service( ServiceManager serviceManager )
{
    myService = (MyService)serviceManager.lookup( MyService.ROLE );
}

better *for the component writer* than this:

public void service ( ServiceManager serviceManager )
{
    proxyFactory = (ProxyFactory)serviceManager.lookup( ProxyFactory.ROLE );
    myService = (MyService)serviceManager.lookup( MyService.ROLE );
}

Yes, I know that they're "different logical things".  But so are, say, 
authentication services and persistence services.  We don't use different 
mechanisms to deliver those services to components.  It would be pointless to 
do so:

public void service( ServiceManager serviceManager )
{
    authService = (MyAuthenticationService)serviceManager.getAuthService( 
MyAuthenticationService.ROLE );
    persistService = (MyPersistService)serviceManager.getPersistService( 
MyPersistService.ROLE );
}

Why bother?  And I'm wondering the same thing of container-provided vs 
peer-provided services:  Why bother?  Does the component care?

Let's look at this another way.  As you pointed out, the most general case is 
to cram every resource into a single directory:

public void contextualize( Context context )
{
    config = (Config)context.get( "well-known-config-name" );
    logger = (Logger)context.get( "well-known-logger-name" );
    homeDir = (File)context.get( "homedir.name" );
    shutdownService = (ShutdownService)context.get( ShutdownService.ROLE );
    myService = (MyService)context.get( MyService.ROLE );
}

But this is pretty useless.  Much better if the meaning of a resource is 
reflected in the framework.  The easy ones first:

public void contextualize( Context context )
{
    config = context.getConfig();
    logger = context.getLogger();
    homeDir = (File)context.get( "homedir.name" );
    myResource = (String)context.get( "myresource.name" );
    shutdownService = (ShutdownService)context.get( ShutdownService.ROLE );
    myService = (MyService)context.get( MyService.ROLE );   
}

Move the resource types we've identified (config and logger) from 
contextualize() to a separate lifecycle method (but that's beside the point 
here).

Now let's try to categorise the remaining resources.  Once we find a good way 
of separating them, then we can add lifecycle methods based on that.

First, try separating passive data and active services:

public void contextualize( Context context )
{
    homeDir = (File)context.get( "homedir.name" );
    myResource = (String)context.get( "myresource.name" );
    shutdownService = (ShutdownService)context.getService( 
ShutdownService.ROLE );
    myService = (MyService)context.getService( MyService.ROLE );
}

Not too bad, kinda matches how I might use the resources in my code:  I treat 
homeDir and myResource as immutable pieces of data, and I ask shutdownService 
and myService to do stuff for me.

Next, try splitting on container-provided vs peer-provided:

public void contextualize( Context context )
{
    homeDir = (File)context.getContainerResource( "homedir.name" );
    myResource = (String)context.getPeerResource( "myresource.name" );
    shutdownService = (ShutdownService)context.getContainerResource( 
ShutdownService.ROLE );
    myService = (MyService)context.getPeerResource( MyService.ROLE );
}

This one doesn't really work.  The component doesn't care that homeDir was 
provided by the container.  Would the component use it any differently if it 
used getPeerResource() to find it?  No.  To the component, a home directory 
is a home directory.  It is not a container-provided home directory or a 
peer-provided home directory.  Same for the services.  A shutdown service is 
a shutdown service.  Nothing more.

The final case is to split on both container-provided vs peer-provided and 
data vs service:

public void contextualize( Context context )
{
    homeDir = (File)context.getContainerData( "homedir.name" );
    myResource = (String)context.getPeerData( "myresource.name" );
    shutdownService = (ShutdownService)context.getContainerService( 
ShutdownService.ROLE );
    myService = (MyService)context.getPeerService( MyService.ROLE );
}

Ug.  Pass :)

So which of these cases do you think offer the most benefit to the component 
writer?  Assume logger, config, params have been split out already:
1. No separation.
2. Separate data and services.
3. Separate container-provided resources and peer-provided resources.
4. Separate container-provided data, container-provided services, 
peer-provided data, and peer-provided services.
5. Who cares?  Why are you bothering me with these questions?

-- 
Adam

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


Mime
View raw message