On Mon, 3 Mar 2003, Bill Burke wrote: > > > > 1. Source located in neutral territory, namely the common module.
ok > > > > 2. Sequence of interceptors determined by (iterator in) invocation object. This could be a modifiable iterator at some point. This allows the interceptor stack to be modified per invocation at runtime if necessary depending on logic in previous interceptor. This type of functionality would call for an authenticated invocation from the client. An example where I want to collect stats from the service I'm invoking. I don't need the relevant interceptors to exist for any other than one or few specific invocations. > > > > 3. Construction of interceptors through interceptor factories. > > ok > > 4. Storing interceptor specific metadata in the invocation factory (e.g. > > for ejbs, this is the currently the Container). This makes it easy to > > write stateless interceptors. Are statless interceptors shared between components or per component. There's experimental system wide shared interceptors in the mx base if that type of functionality appeals to anyone. > > Metadata should be in 2 places. The "class" or "invocation factory", and > the actual instance. > > > 5. multiple interceptor chains per InvocationFactory, e.g. each method > > gets a separate interceptor chain. (Idea from current mbean interceptor > > implementation) > > > > Do we really need per method interceptor chains? We did not need them to > implement EJBs. It makes some interceptors less complex to implement. It makes sense at service interception where we may have a separation between attributes/operations. Say I want to persist 2 out of 3 attributes I'm changing. Operations don't need the persistence interceptor, nor do all the attributes. I find it more intuitive to config separate stacks rather than building one stack with everything in it and then start filtering per method. > > 6. Ability to replace the interceptor interator. This is not directly > > supported now but is essentially what happens when an invocation goes from > > the client interceptor stack to the invoker interceptor stack. (Currently > > the only example of an invoker interceptor stack is the trunk invoker.) > > > > Not sure what you mean by replacement. Do you mean hot-deploy of new > interceptors? I have this now in AOP framework for POJOs. I understood it as modification of the stack per invocation if necessary.. -- Juha ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
