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 then? thx, - LSD -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
