avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Shea <s...@gtsdesign.com>
Subject Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date Wed, 04 Dec 2002 18:05:02 GMT
I've been following this thread with a great deal of interest, since I
have the same questions as Adam has been asking.  My experience with
using Avalon is that Context is great until you get someone else's
container involved in the picture.  At that point it becomes a minor
nightmare, since each container sees it differently.

My views are from the perspective of a component writer who wants to
avoid container lock-in.

I've been willing to adopt the data/services distinction, because the
container I want to use (merlin) does so.  But the data/services
paradigm turns Context into either a less-capable Configuration or a
declaratively-driven object builder.  The idea of Context as an object
builder feels kind of baroque to me, and I can't imagine that all
containers will do it, so in merlin I don't use Context at all.

The container-provided/peer-provided view is one I'd be willing to adopt
also.  In this view, Context is container-dependent, and is simply
anathema to the component writer who wants to maintain cross-container
portability.  That's the extent of my interest.  I can see how this
view would be useful to someone building a tightly-coupled
component/container system, but my goal is to avoid that at all costs.

As you can see, I wouldn't use Context under either of the data/service
or container/peer paradigms.  I think that's ok.

If this discussion had to end today, I'd say Context is a red herring
and should be discarded.  It would be replaced with two new stages:
ObjectConfigurable and ContainerServiceable.

        Gary

[2002-12-04 21:56 +1100] Peter Donald (peter@realityforge.org) wrote:

> 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.
>
> +1
>
> > 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?
>
> :)
>
> --
> Cheers,
>
> 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>
>
>
>


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