On Tue, 3 Dec 2002 13:17, Adam Murdoch wrote:
> Hence my question: Does the component *really* care whether a particular
> resource is provided by the container or not provided by the container? Is
> this an artificial distinction? Why is it useful to the component writer
> to split them?
Essentially it comes down to the context wrt the resources is requested. For
example lets consider Logger. Historically we had LogManager as a service
that components depended on to get at their logger. So it would look
something like;
class MyComponent
{
void service( ServiceManager sm )
{
LoggerManager lm = (LoggerManager)sm.lookup( LoggerManager.ROLE );
m_logger = lm.getLogger( "my-channel" );
}
}
In this case you are passing component specific context (ie string
"my-channel") into LoggerManager. Now if you wanted two different instances
of MyComponent - say one production and one testing - they would both log to
the same channel or we would have to create multiple instances of
LoggerManager.
However when the container manages allocation of Logger resource they can be
remapped without the Component writer knowing about it or caring.
Everything available in the context can either be made into a service or
blended into configuration or both. The problem is that when the resource
(data or service) requires per-component context you end up having a "fake"
provider component per component. So assembly requires mapping of several
"fake" components to the dependencies in the "real" components (ie the ones
you actually care about). You also end up duplicating data between different
stages. ie assembly process names components and links them to resources
resources and those same names need to placed in configuration of "fake"
provider components.
You could say that this could all be auotmated with some PFM but when we went
this path in the past the users complained about the complexity of assembly
process because you have to be aware of the minute details of how the
container does the PFM and so you have not made it easier on users unless
they are already know everything (which are not the ones who need help
anyways).
When more advanced assembly processes come into play (ie different interceptor
chains per component client) you duplicate much more information and add much
more magic. Too complex to manage without a tool and I don't think it is in
our best interests to require a tool to write applications.
--
Cheers,
Peter Donald
*------------------------------------------------*
| The student who is never required to do what |
| he cannot do never does what he can do. |
| - John Stuart Mill |
*------------------------------------------------*
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
