View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3820673#3820673
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3820673 "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 achives 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? 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). 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). 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? ------------------------------------------------------- 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
