[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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
