Peter Donald wrote: > At 02:28 PM 6/20/2002 -0700, you wrote: > >here is a proposal that will allow us to: > > > > - have a well defined relationship between the container and > > component managers [though it doesn't touch on the issue of > > component resolving] > > > > + you could write component managers that will work in any > > container - and be specified at assembly time. > > > > + these new component managers will work alongside the existing > > component managers (allowing for a gentle upgrade path). > > > > - create dynamic proxies, for example: > > > > + tracing of component level method calls. > > > > + aaa (authentication, authorisation, and accounting), an aaa > > proxy could intercept component level method calls. > > > > + release() via the VM's garbage collector. > > > > + sessions could be implemented this way (with only slight > > modifications from my recent email). > > > > - possibly satisfy some of the need for custom markers (as long as > > they are called after initialize). [sessions would probably fit this > > category] > > > > - chain together any of the above (at the whim of the assembler). > > These are neat features and some containers already implement them. However > I don't see any need for them to be associated with lookup mechanism.
ok, I actually forgot to put in a sentence/disclaimer at the end mentioning that it might possibly be more of an implementation thing than a framework thing... but I also was wondering if there is any container extension mechanism that is shared by the Avalon containers - or if there are plans for anything like that? Robert. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
