On 2002.10.20 19:46:52 -0400 marc fleury wrote: > Sounds good, > > > > When are we planing on converting the interceptor to having only a > > single invoke method? I can easily do this with a new abstract > > interceptor that breaks into the two methods based on > > invocation type. > > Any objections? > > not really, it was a needed clean step. > > > Why must the last interceptor, ContainerInterceptor, be > > defined by the > > container? Unless there is a reason, I'm going to move this of the > > container. > > A reflective invoking interceptor is a good idea as it is needed for the > pure aspect interceptors. > > > One more request: stateless vs stateful interceptors. It is clear to me > that both are needed. For example: stateful are easy to code you just > have your variable in there and it is easy. A good example of stateless > (taken from invocation) is the "read-ahead" interceptor. The read-ahead > interceptor lives in the CMP stack (if you coded your CMP stack with > interceptors). > You need to have that information from the client. The client can then > set the "READ-AHEAD" bucket to 3-5 or 20 or whatever it is that he wants > to display, the invocation carries that information under the > "READ-AHEAD" value and the interceptor reads it under that value *from > the invocation*. It is my feeling that this is now a configuration > thingy passed by the XML files. It is good as is, meaning we need the > defaults to be configured by the XML file for all the invocations but > let the Invocation overwrite them. > > Bottom line is that I believe the CMP optimization of READ-AHEAD is a > good example of both coding practices, in fact they show the *need* for > both.
Previously we were on opposite sides of this debate:-) I think for simplicity we should have only stateless interceptors, any interceptor can store per-stack state in a the stack top in a hashmap. I rewrote the mbean interceptors this way, it works fine, but then juha committed a completely different reimplementation. I still haven't had a chance to look at the aspect stuff, I do think --interceptor lifecycle events --stateless interceptors, with interceptor state stored in the stack top keyed by interceptor. --one model of interceptors jboss-wide are essential. david jencks > > > > Does anyone have any general objections to this change? > > > > -- > > xxxxxxxxxxxxxxxxxxxxxxxx > > Dain Sundstrom > > Chief Architect JBossCMP > > JBoss Group, LLC > > xxxxxxxxxxxxxxxxxxxxxxxx > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: > > Access Your PC Securely with GoToMyPC. Try Free Now > https://www.gotomypc.com/s/OSND/DD > _______________________________________________ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ------------------------------------------------------- > This sf.net email is sponsored by: > Access Your PC Securely with GoToMyPC. Try Free Now > https://www.gotomypc.com/s/OSND/DD > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
