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 02:03:34 GMT
On Wed, 4 Dec 2002 11:24 am, Stephen McConnell wrote:

> >This is the problem.  We all agree container-provided services are
> > essential. They must be made available to components.  But we're jumping
> > straight to *how*, without answering the basic question: Are
> > container-provided services *really* any different to the other types of
> > services, from the component's POV?  If the answer is no, then the *how*
> > is already there:  Whack them in ServiceManager.  Done.
> Throwing them into the service manager isn't a problem - and yes - the
> component implementation should not know if something is from a
> container or a peer.   However - the container implementation, when
> building a the component that its going to put into the service manager
> - it needs to know if the component is requesting a privaliged service.

Of course.  But that's the container's problem, right?  So long as the 
container gives the privileged service to the privileged component when it 
asks for it, and refuses to hand over the privileged service to a 
non-privileged component, then everyone's happy.  There's nothing that needs 
to be added to framework to allow a container to do this: it's 
container-specific behaviour, driven (presumably) by container-specific 
assembly info.

The whole issue of access control of services might be a good thing to 
formalise and add to framework, at some point.  But definitely out-of-scope 
for a 'what is a context?' discussion.

> If we take the same concept and apply it to contextualization - and we
> want to extend contextualization in an open way

Not sure what you mean here.  Are you talking about some way for a component 
to contribute resources to another component?

> >Answer my question, and I'll go away.
> >Promise. (but only if you give the answer I want :)
> My answer is that "classic" components should not be aware of where the
> service or data comes from.
> :-)

Ok, good.  So why do "non-classic" components (whatever they are) care?

And the second part of the question:  Do components care whether data and 
services are delivered together, or separately?  Why?

> >>But if context/service seperation dissapeared I know I'm still missing
> >>something important - and I think its about granulirity in lifecycle -
> >
> >Can you expand on what exactly you feel is missing?  Is it just a vague
> >feeling that something is not right?  Or something more specific?
> I have real requireements context level differentiation.  I use in my
> day-to-day work the notion of component profile (component type +
> dependency spec + config). For any given profile I have cases of
> multiple deployed component instances, differentiated by the context
> that I'm providing them with.

Not sure what you mean.  Can you give some example (pseudo-) code?  I'm 
interested in the contextualize() and service() methods of these components.


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