Guys this is a great discussion but it needs to move to www.jboss.org/forums in the Aspects on JBoss forums
marc f > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:jboss-development-admin@;lists.sourceforge.net] On > Behalf Of Bill Burke > Sent: Tuesday, October 22, 2002 4:02 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign > > > > > > -----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 ------------------------------------------------------- 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
