avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [RT] One Container to Rule them all
Date Thu, 27 Jun 2002 07:42:10 GMT
On Thu, 2002-06-27 at 09:11, Peter Donald wrote:
> At 08:57 AM 6/27/2002 +0200, you wrote:
> > > With enough annotations you could almost validate the entire sitemap prior
> > > to deploying it which would probably save a lot of headaches over time.
> >
> >is the current metainfo material you guys are writing startup-only? It
> >has been said cocoon's sitemap changes at runtime
> And I would put it to you that it doesn't. The other Leo has said much the 
> same thing.

hmm. It seems to me that it would be a valid use case to have the
Assembly Profile change at runtime, and not the metainfo itself. ie:
drop in a new component at runtime (say through jmx or a commandline
tool like the axis package has), and the profile changes.

The separation between assembly and metainfo is still a little clouded
in my head, so...

>  > Component Entrys
> > > ----------------
> > >
> > > When a container is managing a component it creates an Entry per 
> > component.
> > > The Entry manages all the runtime information associated with a component.
> >
> >not the Assembly Profile?
> maybe a reference to Profile

hmm. If you see an assembly as possibly changing at runtime, that means
"runtime information" includes a "runtime assembly profile"....maybe in
the next refactoring... ;)

> > > The handlers is one of the main places where the containers will differ.
> > > Some will offer pooling and advanced resource management. Others will 
> > proxy
> > > access to components, maybe offering interceptors etc.
> >
> >what is the minimum? ie what should the-other-leos MicroContainer
> >support?
> See SimpleServiceKernel for an example of basic container. Does little bar 
> run things.

will do. Where is it?

> >do we make it a specification of the standard Profile classes that they
> >are sufficient for Phoenix/Fortress (or do we specify phoenix/fortress
> >don't support more than the standard Profile). I'd like that.
> It is just how they happen to stand at this stage of evolution. 
> Fortres//Phoenix are free to extend them in future if needed.

okay. You're still against formalizing container feature specification



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