marc fleury wrote:
One more request: stateless vs stateful interceptors. It is clear to meCMP will be an set of interceptors so this type of optimization will be trivial.
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.
Based on the work I've already done, I think I can eliminate EntityContainer, StatefullSessionContainer, StatelessSessionContainer and MessageDrivenContainer and replace all of them with the single Container class plus some interceptors. I'm not sure about this yet, but it looks like it will be a simple solution in the end.
-dain
-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
