View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3820725#3820725
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3820725 "[EMAIL PROTECTED]" wrote : "Bill Burke" wrote : I agree with Marc. 99% of use cases wil not want to chance the interceptor stack. try/catch simplifies the programming model. Try - finally simplicity is not a point (if - else achieves the same). Variable visibility for a stateful interceptor however is a good point. So we come back to the discussion of stateless vs. stateful interceptors. If state is needed, should it belong to the interceptor or to the invocation? For JBoss AOP it will not matter as it can be either way. In XML definitions of interceptors you will be able to define the scope of the interceptor. Whether an instance of the interceptor is created perVM, perClass, or perInstance. Currently you can get perVM and perClass because the framework provides a Factory plugin so you could pass in a pointer to an MBean if so desired. Aspects (classes that contain multiple advices) already work in this manner (defining allocation scope). In JBoss AOP intereptor state can also be stored in many different places. PerThread (in a threadlocal), PerInvocation (within the invocation object), PerInstance (within the Object itself), perClassMethod (metadata about the class), perClass(default data for the class). The interceptor asks the invocation to resolve state (metadata) and the invocation resolves it based on the context of the invocation, looking in each of the above "repositories". Eventually I want to add the ability to declare state/metadata defaults VM or Cluster wide, or even the ability to define Configuration Domains so you can define your own path to resolving. I hope myself or somebody eventually ports these ideas to JMX XMBean land. Should all interceptors be stateless and can be shared across POJO's (scalability). Or do we build stateful interceptors -- interceptor instance per POJO (very high number of instances even on a small interceptor stack if a lot of POJO's are instrumented). It should be fully flexible. What you're arguing for (or marc) is an interceptor instance per POJO (when stateful). However, intuition says keep everything stateless as much as possible (that is, let state live within an invocation -- like HTTP -- but the server should remain stateless). The instance scope has nothing to do whether you have different IN/OUT interceptor chains. Should there be a distinction in the interfaces between stateless and stateful interceptors (for instance, the Interceptor and SharedInterceptors that exist in the JMX base)? Do we always require a stack of interceptor instance per POJO? Fully flexible. It is this flexible in JBoss AOP as there is interceptor chains defined for each Class and you can also add interceptors at the instance, per POJO, level. For perClass defined interceptor chains, Aspects already support having the scope of the Aspect instance perVM, perClass, or perInstance. I just haven't ported it to work with interceptors yet. Again, I want this flexiblity in the JMX MBean level. Bill ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
