avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@realityforge.org>
Subject Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date Wed, 04 Dec 2002 10:56:58 GMT
On Wed, 4 Dec 2002 11:07, Adam Murdoch wrote:
> 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? 

Components don't care what the origins of the resource are - all of it is 
potentially "contextualized" on a per component basis and all generally has 
certain criteria to adhere to but beyond that it is about it. The different 
resources are separated out for the sake of humans and no other reason. 

Context is separated from ServiceManager because humans see them as different 
things - especially during the assembly process. 

> 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:

I disagree. If persistence were provided to the component and the component 
was effectively made to be an OJB object or something like that then we would 
likely provide persistence/transaction capabilities in a very different 
manner. Most likely via some transparent EJB-like manner.

In the same way if AAA services were provided to a component as part of it's 
environment then it would likely also follow an EJB/Servlet style setup where 
the container does it via interception and allows components to access it 
programatically via something like

getServletContext().isPrincipleInRole( String role, Principle p );
getSessionContext().isCallerInRole( String role );
(or insert real examples here or JAAS).

If the services are things that the container provides to the component as 
part of it's environment then the user perceives them as different to 
services that the component uses. I can't think of one API that actually 
merges the two concepts.

When we tried to merge the two things together the primary reason we separated 
them out again was because of user complaints. ie If a resources requires 
resources A, B and C and C is container provided. All three are accessed in 
the same way so the person sees them as much the same (like the component 
sees them as much the same). However during assembly they are only required 
to assemble A and B - which creates a cognitive dissonance because they are 
treated as identical in one place but different in another.

> 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?



Peter Donald
| Those who know how to think need no teachers.  |
|                                      - Gandhi  |     

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

View raw message