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. As a side note it looks very similar to the notion of interceptors that is present in both CORBA and J2EE servers. The interceptors could be clientside or serverside and essentially decorate the call or context of call in some way. However interceptors are independent of lookup mechanism even in J2EE. ie use JNDI for lookup/directory services and the thing looked up is a proxy/stub that implements interceptors internally. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
