avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Date Fri, 11 Jan 2002 14:00:58 GMT
On Sat, 12 Jan 2002 00:54, Paulo Gaspar wrote:
> > It may be clearer to use the term ServiceManager rather than
> > ComponentManager
> > because that has a easier to grok description of what a CM is
> > meant to do.
> > For sharing of generic resources that are not services but data
> > then Context
> > is probably the place for it.
> ...this makes it much less confusing. =:o)


> Ok, what I am proposing is for Avalon (Framework + Excalibur) 5 to have a
> brand new ComponentManager which could provide the core functionality for
> the ServiceManager (now called ComponentManager).
> So, Avalon would get BOTH a Service Manager and a Component Manager. This
> would make the framework quite a bit more generic and I think it would be
> of better use for projects like Ant-Myrmidon and Cocoon.

What would be the difference between an Avalon4 Context and an Avalon5 
ComponentManager ?

> I mean, my "Sitemap" does a lot of the same that Cocoon's Sitemap does and
> I just use my standard ComponentManager and Configurator functionality for
> that. They have to do a lot more manually I think.

I think Context is meant to do that. Essentially Avalon4's Context serves 4 
"styles" of context. It actually has similarities to context as defined in 
linguistic theory ;)

1. World Context / Per-Application context: So this describes application 
wide settings. An example may be the working directory of the application.

2. Person Context / Per-Component context: This contains context information 
specific to the component. An example may be the name of the component.

3. Conversation Context / Per-Session context: This contains context 
information specific to the component. An example may be the IP address of 
person who you are talking to.

4. Speach Act Context / Per-Request context: This contains information about 
a specific request in component. Example may include the parameter submitted 
to a particular web form or whatever.

When we implement this (1) and (2) are generally merged into one interface. 
For instance in pheonix we have a block context that among other things has 
two methods. One is getHomeDirectory() and that belongs to (1) while the 
other is getName() which belongs to (2).

(4) is usually passed into a service() style method as parameters. So you may 
have something like

void doMagic( int param1, int param2, Context otherParamsInHere );

When (3) is needed in the system it is usually also passed into the "service" 
method or alternatively it is made available via the context representing (4).

My memory is sketchy but I believe C2 used an Environment object that was 
basically the Per-Request parameters and Per-Session stuff. Though I don't 
think it extended Context or anything like that.

hmm .. maybe I should should condense/clean this explanation and place it in 
the javadocs ... 



| You can't wake a person who is pretending      |
|       to be asleep. -Navajo Proverb.           |

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