> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of David > Jencks > Sent: Monday, October 21, 2002 4:52 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JBoss 4.0 Entity Redesign > > > On 2002.10.21 10:50:45 -0400 Bill Burke wrote: > > 1. Interceptors do not belong in the JMX layer. JMX should > stay simple. > > If > > you want interceptors in front of an MBean, you should make the MBean an > > aspect. Let's gut out the JMX interceptors in favor of using Hiram's > > Aspect > > stuff when its mature enough. > > I disagree. Juha implemented the mbean server based on interceptors for > the same reason most of jboss is based on interceptors. > > I think there should only be one kind of interceptor stack, used for > mbeans, clients, aspects, ejbs. In the server, what's on the top makes it > an mbean. In a client, it can be the proxy. For aspects, maybe something > else. But we only need one kind of interceptor (as in "interface that all > interceptors implement" and "how do we invoke each interceptor in the > stack", not as in "they should all be stateless/ful). >
Yes there should be only one kind of interceptor stack. This is the Aspect framework (all aspects are, are interceptors anyways). JMX worries about deployment, dependencies, management, basically its a lightweight component framework. Aspects provide the interceptors. If you implement an MBean as an Aspect you can use the power of the Aspect framework. Complete separation. As you said, there only needs to be one kind of interceptor stack. This is the Aspect Framework. So both POJOs and MBeans can have interceptors via the Aspect Framework. Unified. > For ejbs, this will translate into a slightly odd kind of mbean, since > there won't exactly be one particular object at the end of the stack, but > rather the instance will get selected by one of the interceptors. > Its not odd at all. The object at the end of the stack is the Interceptor that invokes on the actual EJB. Bill > > > > > 2. I really don't like this idea of storing state in some detached > > hashmap > > somewhere. You're getting back to functional programing with structures > > and > > functions. I agree with Marc, hashmap.getvalue is just plain unreadable > > as > > well. > > > > Hiram, example of state? > > An example is the "Nuke" pattern for replicated SFSB. The state of the > > SFSB > > stays with the client in the vent of a total destruction of the server. > > The > > client provides the state in the event of a failover. > > > > Another is IDEMPOTENT methods. Idenpotent methods return the same value > > no > > matter what. An interceptor knowing this could store the state of the > > returned method call and avoid a remote invocation. > > > > The above are examples of state per instance. Now I believe you would > > have > > singleton interceptors that needed to maintain state. An example is a > > client side interceptor that does clustering, loadbalancing and > failover. > > It needs to maintain a list of available nodes. > > > There are kind of 3 kinds of state: > > Configuration of interceptor instances of the same class, > conceptually from > some kind of interceptor factory. This should definitely be kept in the > interceptor instance. Related to this is "which interceptors are in the > stack". Both of these are currently recorded in jboss.xml as a > config-name > for ejb stacks. > > State of interceptor instances depending not on stack name but on identity > the "top of stack object". This includes, for ejbs, stuff like local jndi > environment, security proxy instances, tx-method associations. I think > this is what we are debating. I think it will lead to significantly > simpler stack management and clearer thinking about interceptors to store > this in a hashmap at the top of the stack. If this state info is > stored in > the interceptors, you need an instance of the interceptor for each "top of > stack object". If it is store in the "top of stack object", you only need > one instance of each interceptor for each stack definition. > > Currently, most interceptors are stateless in this way, although many > already are stateless because they store the state info in the "top of > stack object". I'm proposing that we formalize this and make the > remaining > interceptors (such as security proxy) use this model as well. > > Thirdly, there is state from the method invocation. I think everyone > agrees that this state should stay in the method invocation, and we should > not create and configure a stack for each invocation. > > david jencks > > > > > > Bill > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:jboss-development-admin@;lists.sourceforge.net]On Behalf Of > > Hiram > > > Chirino > > > Sent: Sunday, October 20, 2002 11:25 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign > > > > > > > > > > > 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. > > > > > > > > David there is no reason to enforce one. We need both coding styles > > it > > > > is easier. I don't think it is easier to always code > > > > > > > > invocation.getValue("COMMIT-OPTION"); > > > > > > > > as opposed to > > > > > > > > commitOption > > > > > > > > when the commit option is configured at deployment. Clearly we can > > > > achieve the same result but there is we shouldn't enforce one. > > > > > > > > > > When you guys talk about statefullness.. I get a little lost. Marc, > > is > > > that "commitOption" statefull: > > > > > > (1) per proxy interceptor instance. 1 interceptor instance is created > > for > > > each DP. > > > (2) per stack interceptor instance. 1 interceptor instance is > > > created for a > > > stack (shared by DP). > > > > > > Right now the aspect stuff does (2), but you can do the > > > invocation.attachments.get("COMMIT-OPTION"); to get a value that was > > > attached to the DP. > > > > > > Regards, > > > Hiram > > > > > > > > > > > > ------------------------------------------------------- > > > 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:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > ------------------------------------------------------- > 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;7576298;k?http://www.sun.com /javavote _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- 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
