RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
On 2003.03.09 15:20 Bill Burke wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > David > > Jencks > > Sent: Saturday, March 08, 2003 8:23 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] Proposal for jboss-wide interceptor framework > > > > > > > > > > > 5. multiple interceptor chains per InvocationFactory, e.g. > > each method > > > > gets a separate interceptor chain. (Idea from current mbean > > interceptor > > > > implementation) > > > > > > > > > > Do we really need per method interceptor chains? We did not > > need them to > > > implement EJBs. > > > > > > > After working with them a little bit with mbeans for jca 1.5 > deployment, > > I conclude Yes, we absolutely need per-method interceptor chains!! they > > make life so much simpler I can't believe it. > > > > What are you planning to use? The AOP framework as is can only define > interception for Java classes and Dynamic Proxies. If you need MBean > interception, it is not there unless you want to use the Java class > interception. Or, if you want a DP you'll have to change how MBeans are > registered with the server. > > > I'm less convinced that relying on a fixed sequence of interceptor > > factories to generate every chain is the best design. I implemented a > > quick and dirty way of generating custom chains by simply looking in > the > > mbean metadata for a list of interceptor classes. This strikes > > me as a lot > > more convenient for my purposes than having to construct some long > > interceptor factory list that can be used for any chain. I think > > generating the interceptor chains needs some more thought. > > > > Can you explain what you mean by chain? You're thinking a chain for each > method? You're saying its easier to define a chain for each method > rather > than to define a chain for the whole object? definitely. Why can't we have both? > There's no reason why not. sure, this is fine, my proposed interceptor design should let you do this easily. I don't quite see how to fit it into your current aop stuff easily. For the moment I am just using the jmx interceptors and they are working fine. One of my points here is that I think the purpose of the InterceptorFilter is to simulate per-method chains (based on the comment "we should cache the results of calling the filter"), and I think actual per-method chains are a much clearer and cleaner implementation. Certainly the current implementation of InvocationFilter is silly, all it does is make 2 method calls instead of one. > > > > Bill, my impression is that you are planning to use your AOP framework > > as-is for the ejb conversion. Is there anything I can do to influence > you > > towards using per-method interceptors from the start? Or do you think > two > > smaller rewrites is a better plan than one larger rewrite? > > > > No where in our entire EJB/J2EE codebase do we use per-method > interceptors. Jmx has had per method interceptors for many months. I'm just putting them to use. > > The use of the AOP Invocation object nor the Interceptor interface > effects > configuration or whether or not there are method chains or not. ?? Can't decipher what you are trying to say here. Thanks david > > Bill > > > > --- > This SF.net email is sponsored by: Etnus, makers of TotalView, The > debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > > disoriented. TotalView can help you find your way. Available on major > UNIX > and Linux platforms. Try it free. www.etnus.com > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Saturday, March 08, 2003 8:23 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Proposal for jboss-wide interceptor framework > > > > > > > 5. multiple interceptor chains per InvocationFactory, e.g. > each method > > > gets a separate interceptor chain. (Idea from current mbean > interceptor > > > implementation) > > > > > > > Do we really need per method interceptor chains? We did not > need them to > > implement EJBs. > > > > After working with them a little bit with mbeans for jca 1.5 deployment, > I conclude Yes, we absolutely need per-method interceptor chains!! they > make life so much simpler I can't believe it. > What are you planning to use? The AOP framework as is can only define interception for Java classes and Dynamic Proxies. If you need MBean interception, it is not there unless you want to use the Java class interception. Or, if you want a DP you'll have to change how MBeans are registered with the server. > I'm less convinced that relying on a fixed sequence of interceptor > factories to generate every chain is the best design. I implemented a > quick and dirty way of generating custom chains by simply looking in the > mbean metadata for a list of interceptor classes. This strikes > me as a lot > more convenient for my purposes than having to construct some long > interceptor factory list that can be used for any chain. I think > generating the interceptor chains needs some more thought. > Can you explain what you mean by chain? You're thinking a chain for each method? You're saying its easier to define a chain for each method rather than to define a chain for the whole object? Why can't we have both? There's no reason why not. > Bill, my impression is that you are planning to use your AOP framework > as-is for the ejb conversion. Is there anything I can do to influence you > towards using per-method interceptors from the start? Or do you think two > smaller rewrites is a better plan than one larger rewrite? > No where in our entire EJB/J2EE codebase do we use per-method interceptors. The use of the AOP Invocation object nor the Interceptor interface effects configuration or whether or not there are method chains or not. Bill --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
The AOP case is even more similar to the DP if you think of AOP like this: If the AOP intrumented methods are: < Interceptors are: [] The original (but renamed) object methods are: ( The object is: O An AOP stack then is: <[](O Which is almost the same as the DP case: |[](O Regards, Hiram > If an object is > > |(O > > | is the interface > ( are the methods to the object > O is the actual implementation > > or > (O for a pojo > > then using > > |[](O > is the DP approach where the [] interception is like > the current EJB > implementation and what Hiram was proposing to do in > the very beginning > > ([]O > is the current AOP approach for POJO's. > > > There shouldn't be a war in these two approaches and > the interface one > should systematically use DP > > marcf > __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
> > > 5. multiple interceptor chains per InvocationFactory, e.g. each method > > gets a separate interceptor chain. (Idea from current mbean interceptor > > implementation) > > > > Do we really need per method interceptor chains? We did not need them to > implement EJBs. > After working with them a little bit with mbeans for jca 1.5 deployment, I conclude Yes, we absolutely need per-method interceptor chains!! they make life so much simpler I can't believe it. I'm less convinced that relying on a fixed sequence of interceptor factories to generate every chain is the best design. I implemented a quick and dirty way of generating custom chains by simply looking in the mbean metadata for a list of interceptor classes. This strikes me as a lot more convenient for my purposes than having to construct some long interceptor factory list that can be used for any chain. I think generating the interceptor chains needs some more thought. Bill, my impression is that you are planning to use your AOP framework as-is for the ejb conversion. Is there anything I can do to influence you towards using per-method interceptors from the start? Or do you think two smaller rewrites is a better plan than one larger rewrite? thanks david jencks --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
> It makes some interceptors less complex to implement. It > makes sense at service interception where we may have a > separation between attributes/operations. Say I want to > persist 2 out of 3 attributes I'm changing. Operations don't > need the persistence interceptor, nor do all the attributes. clearly the cache/persistence implementation are a justification of the method scoped interception Like bill showed at BootCamp I think the levels are method/instance/application (logical)/class/VM/cluster. today we have application only in EJB level where the logical scope is the EJB container and the JNDI/JMX name that identifies it. Dain does kindof interception on the abstract getter/setter so the method one is there. marcf --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
> , #2, and #3a if I can focus solely on this for 5 days with > no interuptions. OK I will guarantee the no interuptions. Get it fucking done and you will put us all on top of the middleware world. JNDI is the simplest test case as Scott pointed and something I wanted see done in a long time marcf --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
yes, I think this could be a war-less decision :) DP/interfaces required for remoting. Get/set required for cache/cmp instrumentation on AOP. There are some grey areas as to when we require interfaces and plain POJO for server only stuff. As Scott pointed out the JNDI rewrite as a AOP/DP or AOP/POJO service is a requirement to test our stuff. Securing the JNDI access would be done very simply with the framework wether it is behind an interface or methods of pojo is completely irrelevant except that interface is required for DP/remote which is the case ANYWAY as we use the J2EE interface definition of JNDI. If an object is |(O | is the interface ( are the methods to the object O is the actual implementation or (O for a pojo then using |[](O is the DP approach where the [] interception is like the current EJB implementation and what Hiram was proposing to do in the very beginning ([]O is the current AOP approach for POJO's. There shouldn't be a war in these two approaches and the interface one should systematically use DP marcf > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Bill Burke > Sent: Monday, March 03, 2003 2:09 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Proposal for jboss-wide interceptor framework > > > The AOP framework really right now is only for POJO > interception. I do have the beginnings of DynamicProxies > though. The AOP POJO framework can intercept static and > member methods, constructors, and fields. YOu can define > metadata on a class via xml, as well as interceptor stacks at > the Class level. You can add interceptors to a specific > instance at runtime. I have ported 2 interceptors so far to > the AOP framework. TX and Security. Security compiles but is > currently untested. > > For a minimum, I'd like everybody to at least use the > Invocation object I've created for the AOP framework. The > payloads in the server/src/org/jboss/invocation/Invocation > object have been abstracted into > its own object (SimpleMetaData). The Invocation object holds the > interceptor chain and is typeless as well. What I mean by > typeless is that the Invocation object can be used for any > type of invocation. Method, field, Constructor, JMS message, > whatever. > > I'd like to finish the beginnings of the DP framework and > apply them to EJB client-side interceptors but am having a > hard time getting more than an hour at a time to focus on > this big change. > > For JMX, you can already define AOP interceptors just like > you would for any Java class. This isn't a complete solution > for JMX though since JMX is instance based and not class > based. The AOP framework has a concept of pointcuts. I'd > like to add a MBean pointcut. What will happen is all MBean > classes will be instrumented by the AOP framework. The AOP > manager will deploy JMX pointcuts/interceptions by adding > interceptors per MBean. The AOP framework already supports > adding interceptors to a specific Object instance. Its just > a matter of hooking up the configuration mechanism. I'm not > sure if this is a good enough solution yet. > > As far as remoting goes for AOP, I want to first go the > DynamicProxy route. If a user wants to remote a POJO, a > DynamicProxy is created and remote invocations go through > this proxy. EJB currently has client interceptors grouped as > proxy-invoker binding. I think this is the kind of approach > we could use for AOP at first. > > For EJBs, I think it is just a matter of finishing the AOP DP > framework and using it for client interceptors. This will > force EJBs to use the AOP Invocation object and to access > interceptors the same way as AOP, which is a little different. > > JMX remoting is a problem though because the client can > dynamically create a connection to an MBean via JMX > connectors. The problem is, how do you get the client-side > interceptor chain back to the client when the client creates > a connection? We don't have this problem with JNDI or EJB > because the client must go to a specific port (JNDI) or > repository(EJB to JNDI) and we can provide the client DPs there. > > My problem right now with all this stuff is that I cannot > seem to focus on it for more than an hour without getting > interrupted to do something else. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > > Nathan Phelps > > Sent: Sunday, March 02, 2003 4:17 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] Proposal for jboss-wide > interceptor framework > &g
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
On Mon, 3 Mar 2003, Bill Burke wrote: > > > > 1. Source located in neutral territory, namely the common module. ok > > > > 2. Sequence of interceptors determined by (iterator in) invocation object. This could be a modifiable iterator at some point. This allows the interceptor stack to be modified per invocation at runtime if necessary depending on logic in previous interceptor. This type of functionality would call for an authenticated invocation from the client. An example where I want to collect stats from the service I'm invoking. I don't need the relevant interceptors to exist for any other than one or few specific invocations. > > > > 3. Construction of interceptors through interceptor factories. > > ok > > 4. Storing interceptor specific metadata in the invocation factory (e.g. > > for ejbs, this is the currently the Container). This makes it easy to > > write stateless interceptors. Are statless interceptors shared between components or per component. There's experimental system wide shared interceptors in the mx base if that type of functionality appeals to anyone. > > Metadata should be in 2 places. The "class" or "invocation factory", and > the actual instance. > > > 5. multiple interceptor chains per InvocationFactory, e.g. each method > > gets a separate interceptor chain. (Idea from current mbean interceptor > > implementation) > > > > Do we really need per method interceptor chains? We did not need them to > implement EJBs. It makes some interceptors less complex to implement. It makes sense at service interception where we may have a separation between attributes/operations. Say I want to persist 2 out of 3 attributes I'm changing. Operations don't need the persistence interceptor, nor do all the attributes. I find it more intuitive to config separate stacks rather than building one stack with everything in it and then start filtering per method. > > 6. Ability to replace the interceptor interator. This is not directly > > supported now but is essentially what happens when an invocation goes from > > the client interceptor stack to the invoker interceptor stack. (Currently > > the only example of an invoker interceptor stack is the trunk invoker.) > > > > Not sure what you mean by replacement. Do you mean hot-deploy of new > interceptors? I have this now in AOP framework for POJOs. I understood it as modification of the stack per invocation if necessary.. -- Juha --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
persistence is not realistic for a prototype. The rest is. , #2, and #3a if I can focus solely on this for 5 days with no interuptions. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Scott > M Stark > Sent: Monday, March 03, 2003 3:50 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Proposal for jboss-wide interceptor framework > > > And I'm saying I want a prototype that demonstrates how the > various interceptor > offerings work in the context of a real service. Part of the > testsuite for a given > interceptor framework needs to demonstrate the following in order > of increasing > functionality: > > 1. Allow for user defined interceptors to be added to the > NamingService mbean. How is > this defined and where is the integration with the NamingService > deployment. Wouldn't take too long on the server side. I've already described how I would do it with AOP. > 2. Allow for remoting of the org.jnp.interfaces.Naming interface > of the NamingService. How > is this defined and where is the integration with the > NamingService deployment. > 3a. Allow for integration of role based security for lookups > using the JaasSecurityManagerService > and the java:/jaas/some-domain binding of the JaasSecurityManager. How > is this defined and where is the integration with the > NamingService deployment. Along with my response to #1, I've already ported the security interceptors to AOP interceptor framework. I just need to test. AOP configuration will need an extension for JMX, but I don't think it would take long. > 3b. Allow for persistence of binding to the filesystem. How > is this defined and where is the integration with the > NamingService deployment. > This would take longer. If we can do 1-3a with the proposed AOP framework, then we can do 3b. > This is what this generation of JBoss is supposed to be about. > Let's see this for every > variation of interceptor framework as a throw-away testcase. > Agreeing on a framework > without such an excercise and then attacking the codebase enmass > makes no sense to me > right now. > I have applied the AOP framework to both TX and security and they seem to fit for POJOs. I have some notes and have thought extensively how it will integrate with EJBs and JMX. Its just a matter of shutting up and doing it. > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - Original Message - > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL > PROTECTED]> > Sent: Monday, March 03, 2003 11:16 AM > Subject: RE: [JBoss-dev] Proposal for jboss-wide interceptor framework > > > > On 2003.03.02 16:16 Nathan Phelps wrote: > > > > > > I agree. > > With what, specifically? > > > > As I begin the development of JMS/JBoss 4.0, I'm, frankly, > > > confused as to which direction to go concerning the interceptor > > > framework--which project is THE project? There is some great > work being > > > done right now by a variety of people on this problem, but I have no > > > idea how it all fits together--if it fits together. I wish we could > > > settle this problem, agree on which direction we are going, > and then get > > > the code base stabilized so those of us building services > that will use > > > THE framework can have the confidence that we're working with > the right > > > one and that it works as advertised. > > > > Well, before my contribution we had at least 4 incompatible interceptor > > models and a lot of lip service about eventually merging them. > To me it is > > clear that we could make any of the existing models work everywhere. > > Interceptors are not rocket science. Unifying them is primarily an > > exercise in agreeing on which features we want. Since my > initial attempt > > to start discussion on this topic has only provoked wails of dismay from > > people who have not recently implemented interceptor models in > jboss and no > > response from those who have, I'll try to explain the features I have > > attempted to include. > > > > 1. Source located in neutral territory, namely the common module. > > > > 2. Sequence of interceptors determined by (iterator in) > invocation object. > > > > 3. Construction of interceptors through interceptor factories. > > > > 4. Storing interceptor specific metadata in the invocation factory (e.g. &g
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
First, thanks for responding. On 2003.03.03 15:29 Bill Burke wrote: > > > > -Original Message- > > From: David Jencks [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 03, 2003 2:17 PM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] Proposal for jboss-wide interceptor framework > > > > > > On 2003.03.02 16:16 Nathan Phelps wrote: > > > > > > I agree. > > With what, specifically? > > > > As I begin the development of JMS/JBoss 4.0, I'm, frankly, > > > confused as to which direction to go concerning the interceptor > > > framework--which project is THE project? There is some great work > being > > > done right now by a variety of people on this problem, but I have no > > > idea how it all fits together--if it fits together. I wish we could > > > settle this problem, agree on which direction we are going, and then > get > > > the code base stabilized so those of us building services that will > use > > > THE framework can have the confidence that we're working with the > right > > > one and that it works as advertised. > > > > Well, before my contribution we had at least 4 incompatible interceptor > > models and a lot of lip service about eventually merging them. > > To me it is > > clear that we could make any of the existing models work everywhere. > > Interceptors are not rocket science. Unifying them is primarily an > > exercise in agreeing on which features we want. Since my initial > attempt > > to start discussion on this topic has only provoked wails of dismay > from > > people who have not recently implemented interceptor models in > > jboss and no > > response from those who have, I'll try to explain the features I have > > attempted to include. > > > > 1. Source located in neutral territory, namely the common module. > > > > 2. Sequence of interceptors determined by (iterator in) invocation > object. > > > > 3. Construction of interceptors through interceptor factories. > > > > 4. Storing interceptor specific metadata in the invocation factory > (e.g. > > for ejbs, this is the currently the Container). This makes it easy to > > write stateless interceptors. > > > > Metadata should be in 2 places. The "class" or "invocation factory", and > the actual instance. I keep your design for list of metadatas: however I gave the InvocationFactory and additional SimpleMetadata that the InterceptorFactories can use to put metadata in, and I put it at the end of the list of metadatas so it can be overridden. > > > 5. multiple interceptor chains per InvocationFactory, e.g. each method > > gets a separate interceptor chain. (Idea from current mbean interceptor > > implementation) > > > > Do we really need per method interceptor chains? We did not need them to > implement EJBs. Juha thought they were a good enough idea to implement them for mbeans. You put in interceptor filters, and I think multiple chains is better way of implementing the same idea. Lastly, they can avoid a lot of confusing conditional logic in an interceptor: the TxSupport class is really designed to be a set of method-specific interceptors so you don't need a method to txsupport map. > > > 6. Ability to replace the interceptor interator. This is not directly > > supported now but is essentially what happens when an invocation goes > from > > the client interceptor stack to the invoker interceptor stack. > (Currently > > the only example of an invoker interceptor stack is the trunk invoker.) > > > > Not sure what you mean by replacement. Do you mean hot-deploy of new > interceptors? I have this now in AOP framework for POJOs. No. A typical ejb remote call needs to go through 4 interceptor stacks: client interceptors, client side transport interceptors (HA "sprayer" and InvokerXAResource anyway), server side transport interceptors (no examples yet, waiting for this to stabilize a bit) and the server side ejb interceptors. AFAIK we can either replace the interceptor iterator at each junction or construct a new Invocation object. I thought it would be simpler to replace the interceptor iterator. Hot deploy of new interceptors seems pretty cool. I'll have to look at how you do it. david > > > > > I'd really appreciate review of my proposed implementation by Bill, > Juha, > > Dain, and Jeff (and anyone else who has worked on interceptor design > that > > I'm not aware of). In particular I sus
Re: [JBoss-dev] Proposal for jboss-wide interceptor framework
And I'm saying I want a prototype that demonstrates how the various interceptor offerings work in the context of a real service. Part of the testsuite for a given interceptor framework needs to demonstrate the following in order of increasing functionality: 1. Allow for user defined interceptors to be added to the NamingService mbean. How is this defined and where is the integration with the NamingService deployment. 2. Allow for remoting of the org.jnp.interfaces.Naming interface of the NamingService. How is this defined and where is the integration with the NamingService deployment. 3a. Allow for integration of role based security for lookups using the JaasSecurityManagerService and the java:/jaas/some-domain binding of the JaasSecurityManager. How is this defined and where is the integration with the NamingService deployment. 3b. Allow for persistence of binding to the filesystem. How is this defined and where is the integration with the NamingService deployment. This is what this generation of JBoss is supposed to be about. Let's see this for every variation of interceptor framework as a throw-away testcase. Agreeing on a framework without such an excercise and then attacking the codebase enmass makes no sense to me right now. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, March 03, 2003 11:16 AM Subject: RE: [JBoss-dev] Proposal for jboss-wide interceptor framework > On 2003.03.02 16:16 Nathan Phelps wrote: > > > > I agree. > With what, specifically? > > As I begin the development of JMS/JBoss 4.0, I'm, frankly, > > confused as to which direction to go concerning the interceptor > > framework--which project is THE project? There is some great work being > > done right now by a variety of people on this problem, but I have no > > idea how it all fits together--if it fits together. I wish we could > > settle this problem, agree on which direction we are going, and then get > > the code base stabilized so those of us building services that will use > > THE framework can have the confidence that we're working with the right > > one and that it works as advertised. > > Well, before my contribution we had at least 4 incompatible interceptor > models and a lot of lip service about eventually merging them. To me it is > clear that we could make any of the existing models work everywhere. > Interceptors are not rocket science. Unifying them is primarily an > exercise in agreeing on which features we want. Since my initial attempt > to start discussion on this topic has only provoked wails of dismay from > people who have not recently implemented interceptor models in jboss and no > response from those who have, I'll try to explain the features I have > attempted to include. > > 1. Source located in neutral territory, namely the common module. > > 2. Sequence of interceptors determined by (iterator in) invocation object. > > 3. Construction of interceptors through interceptor factories. > > 4. Storing interceptor specific metadata in the invocation factory (e.g. > for ejbs, this is the currently the Container). This makes it easy to > write stateless interceptors. > > 5. multiple interceptor chains per InvocationFactory, e.g. each method > gets a separate interceptor chain. (Idea from current mbean interceptor > implementation) > > 6. Ability to replace the interceptor interator. This is not directly > supported now but is essentially what happens when an invocation goes from > the client interceptor stack to the invoker interceptor stack. (Currently > the only example of an invoker interceptor stack is the trunk invoker.) > > > I'd really appreciate review of my proposed implementation by Bill, Juha, > Dain, and Jeff (and anyone else who has worked on interceptor design that > I'm not aware of). In particular I suspect the serialization support will > need fairly extensive modification to fit with the remoting framework. > > I think of my proposal as pretty much based on Bill's aop interceptor > design with primarily stylistic changes (and the method specific > interceptor chains from mbeans). > > All comments on the proposal's design and implementation welcome. > > Like Nathan, I want the question of what interceptor framework we are going > to use to be settled soon since both the dtm and deployment of jca 1.5 > adapters depend on it. I'm not really interested in developing these > features twice for two different models
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
> -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED] > Sent: Monday, March 03, 2003 2:17 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Proposal for jboss-wide interceptor framework > > > On 2003.03.02 16:16 Nathan Phelps wrote: > > > > I agree. > With what, specifically? > > As I begin the development of JMS/JBoss 4.0, I'm, frankly, > > confused as to which direction to go concerning the interceptor > > framework--which project is THE project? There is some great work being > > done right now by a variety of people on this problem, but I have no > > idea how it all fits together--if it fits together. I wish we could > > settle this problem, agree on which direction we are going, and then get > > the code base stabilized so those of us building services that will use > > THE framework can have the confidence that we're working with the right > > one and that it works as advertised. > > Well, before my contribution we had at least 4 incompatible interceptor > models and a lot of lip service about eventually merging them. > To me it is > clear that we could make any of the existing models work everywhere. > Interceptors are not rocket science. Unifying them is primarily an > exercise in agreeing on which features we want. Since my initial attempt > to start discussion on this topic has only provoked wails of dismay from > people who have not recently implemented interceptor models in > jboss and no > response from those who have, I'll try to explain the features I have > attempted to include. > > 1. Source located in neutral territory, namely the common module. > > 2. Sequence of interceptors determined by (iterator in) invocation object. > > 3. Construction of interceptors through interceptor factories. > > 4. Storing interceptor specific metadata in the invocation factory (e.g. > for ejbs, this is the currently the Container). This makes it easy to > write stateless interceptors. > Metadata should be in 2 places. The "class" or "invocation factory", and the actual instance. > 5. multiple interceptor chains per InvocationFactory, e.g. each method > gets a separate interceptor chain. (Idea from current mbean interceptor > implementation) > Do we really need per method interceptor chains? We did not need them to implement EJBs. > 6. Ability to replace the interceptor interator. This is not directly > supported now but is essentially what happens when an invocation goes from > the client interceptor stack to the invoker interceptor stack. (Currently > the only example of an invoker interceptor stack is the trunk invoker.) > Not sure what you mean by replacement. Do you mean hot-deploy of new interceptors? I have this now in AOP framework for POJOs. > > I'd really appreciate review of my proposed implementation by Bill, Juha, > Dain, and Jeff (and anyone else who has worked on interceptor design that > I'm not aware of). In particular I suspect the serialization support will > need fairly extensive modification to fit with the remoting framework. > If we go the DP route, I don't think serialization is much of a problem since we've already figured most of this out with EJBs. What we DO have to implement is a generic reference object. For instance, a reference to an EJB, MBean, whatever. This is needed so that the transport mechanism can marshall the reference with the correct transport and client-interceptor chain. > I think of my proposal as pretty much based on Bill's aop interceptor > design with primarily stylistic changes (and the method specific > interceptor chains from mbeans). > > All comments on the proposal's design and implementation welcome. > > Like Nathan, I want the question of what interceptor framework we > are going > to use to be settled soon since both the dtm and deployment of jca 1.5 > adapters depend on it. I'm not really interested in developing these > features twice for two different models. > > thanks > david jencks > > > > > Thanks, > > > > Nathan > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Scott M Stark > > Sent: Sunday, March 02, 2003 1:37 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] Proposal for jboss-wide interceptor framework > > > > Woa, before we have a full fledged interceptor war show up in main what > > is the > > status of the various JMX, AOP, etc interceptors and associated > > frameworks?
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
On 2003.03.02 16:16 Nathan Phelps wrote: > > I agree. With what, specifically? As I begin the development of JMS/JBoss 4.0, I'm, frankly, > confused as to which direction to go concerning the interceptor > framework--which project is THE project? There is some great work being > done right now by a variety of people on this problem, but I have no > idea how it all fits together--if it fits together. I wish we could > settle this problem, agree on which direction we are going, and then get > the code base stabilized so those of us building services that will use > THE framework can have the confidence that we're working with the right > one and that it works as advertised. Well, before my contribution we had at least 4 incompatible interceptor models and a lot of lip service about eventually merging them. To me it is clear that we could make any of the existing models work everywhere. Interceptors are not rocket science. Unifying them is primarily an exercise in agreeing on which features we want. Since my initial attempt to start discussion on this topic has only provoked wails of dismay from people who have not recently implemented interceptor models in jboss and no response from those who have, I'll try to explain the features I have attempted to include. 1. Source located in neutral territory, namely the common module. 2. Sequence of interceptors determined by (iterator in) invocation object. 3. Construction of interceptors through interceptor factories. 4. Storing interceptor specific metadata in the invocation factory (e.g. for ejbs, this is the currently the Container). This makes it easy to write stateless interceptors. 5. multiple interceptor chains per InvocationFactory, e.g. each method gets a separate interceptor chain. (Idea from current mbean interceptor implementation) 6. Ability to replace the interceptor interator. This is not directly supported now but is essentially what happens when an invocation goes from the client interceptor stack to the invoker interceptor stack. (Currently the only example of an invoker interceptor stack is the trunk invoker.) I'd really appreciate review of my proposed implementation by Bill, Juha, Dain, and Jeff (and anyone else who has worked on interceptor design that I'm not aware of). In particular I suspect the serialization support will need fairly extensive modification to fit with the remoting framework. I think of my proposal as pretty much based on Bill's aop interceptor design with primarily stylistic changes (and the method specific interceptor chains from mbeans). All comments on the proposal's design and implementation welcome. Like Nathan, I want the question of what interceptor framework we are going to use to be settled soon since both the dtm and deployment of jca 1.5 adapters depend on it. I'm not really interested in developing these features twice for two different models. thanks david jencks > > Thanks, > > Nathan > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Scott M Stark > Sent: Sunday, March 02, 2003 1:37 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Proposal for jboss-wide interceptor framework > > Woa, before we have a full fledged interceptor war show up in main what > is the > status of the various JMX, AOP, etc interceptors and associated > frameworks? > It seems like several people are running around writing this without > demonstrating > how it applies to the existing services. A simple example is how do I > expose the > existing JNDI naming service via RMI/JRMP and RMI/HTTP with that ability > to introduce security and persistence? > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > > --- > 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 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
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
The AOP framework really right now is only for POJO interception. I do have the beginnings of DynamicProxies though. The AOP POJO framework can intercept static and member methods, constructors, and fields. YOu can define metadata on a class via xml, as well as interceptor stacks at the Class level. You can add interceptors to a specific instance at runtime. I have ported 2 interceptors so far to the AOP framework. TX and Security. Security compiles but is currently untested. For a minimum, I'd like everybody to at least use the Invocation object I've created for the AOP framework. The payloads in the server/src/org/jboss/invocation/Invocation object have been abstracted into its own object (SimpleMetaData). The Invocation object holds the interceptor chain and is typeless as well. What I mean by typeless is that the Invocation object can be used for any type of invocation. Method, field, Constructor, JMS message, whatever. I'd like to finish the beginnings of the DP framework and apply them to EJB client-side interceptors but am having a hard time getting more than an hour at a time to focus on this big change. For JMX, you can already define AOP interceptors just like you would for any Java class. This isn't a complete solution for JMX though since JMX is instance based and not class based. The AOP framework has a concept of pointcuts. I'd like to add a MBean pointcut. What will happen is all MBean classes will be instrumented by the AOP framework. The AOP manager will deploy JMX pointcuts/interceptions by adding interceptors per MBean. The AOP framework already supports adding interceptors to a specific Object instance. Its just a matter of hooking up the configuration mechanism. I'm not sure if this is a good enough solution yet. As far as remoting goes for AOP, I want to first go the DynamicProxy route. If a user wants to remote a POJO, a DynamicProxy is created and remote invocations go through this proxy. EJB currently has client interceptors grouped as proxy-invoker binding. I think this is the kind of approach we could use for AOP at first. For EJBs, I think it is just a matter of finishing the AOP DP framework and using it for client interceptors. This will force EJBs to use the AOP Invocation object and to access interceptors the same way as AOP, which is a little different. JMX remoting is a problem though because the client can dynamically create a connection to an MBean via JMX connectors. The problem is, how do you get the client-side interceptor chain back to the client when the client creates a connection? We don't have this problem with JNDI or EJB because the client must go to a specific port (JNDI) or repository(EJB to JNDI) and we can provide the client DPs there. My problem right now with all this stuff is that I cannot seem to focus on it for more than an hour without getting interrupted to do something else. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Nathan Phelps > Sent: Sunday, March 02, 2003 4:17 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Proposal for jboss-wide interceptor framework > > > > I agree. As I begin the development of JMS/JBoss 4.0, I'm, frankly, > confused as to which direction to go concerning the interceptor > framework--which project is THE project? There is some great work being > done right now by a variety of people on this problem, but I have no > idea how it all fits together--if it fits together. I wish we could > settle this problem, agree on which direction we are going, and then get > the code base stabilized so those of us building services that will use > THE framework can have the confidence that we're working with the right > one and that it works as advertised. > > Thanks, > > Nathan > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Scott M Stark > Sent: Sunday, March 02, 2003 1:37 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Proposal for jboss-wide interceptor framework > > Woa, before we have a full fledged interceptor war show up in main what > is the > status of the various JMX, AOP, etc interceptors and associated > frameworks? > It seems like several people are running around writing this without > demonstrating > how it applies to the existing services. A simple example is how do I > expose the > existing JNDI naming service via RMI/JRMP and RMI/HTTP with that ability > to introduce security and persistence? > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
I agree. As I begin the development of JMS/JBoss 4.0, I'm, frankly, confused as to which direction to go concerning the interceptor framework--which project is THE project? There is some great work being done right now by a variety of people on this problem, but I have no idea how it all fits together--if it fits together. I wish we could settle this problem, agree on which direction we are going, and then get the code base stabilized so those of us building services that will use THE framework can have the confidence that we're working with the right one and that it works as advertised. Thanks, Nathan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Sunday, March 02, 2003 1:37 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Proposal for jboss-wide interceptor framework Woa, before we have a full fledged interceptor war show up in main what is the status of the various JMX, AOP, etc interceptors and associated frameworks? It seems like several people are running around writing this without demonstrating how it applies to the existing services. A simple example is how do I expose the existing JNDI naming service via RMI/JRMP and RMI/HTTP with that ability to introduce security and persistence? Scott Stark Chief Technology Officer JBoss Group, LLC --- 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
Re: [JBoss-dev] Proposal for jboss-wide interceptor framework
Step 1 would be just the jndi server mbean and remoting which is why this is as simply as it gets. Beyond that is how to integrate other services via the aop stuff. I want to see how the existing services are going to use these new frameworks. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, March 02, 2003 12:17 PM Subject: Re: [JBoss-dev] Proposal for jboss-wide interceptor framework > No No!! War War War!!! > > :-)) > > Actually I just wanted to get the discussion started early on and try to > get people involved since I think it will be a big undertaking to convert > all the interceptor models to a single one. I don't want to spring an > entire system conversion on anyone without a lot of warning. > > I don't see how your proposed example is simple since I think it involves > at least converting the remoting framework and probably the aop stuff. > > I was thinking of working in this order: > > mbeans > remoting > client interceptors > ejb interceptors > other. > > Aop could be converted at any time Bill agrees: I think this model is close > enough to his that this conversion should be fairly easy. I think the main > difference is the per-method interceptor stacks, which can probably be not > used at first. > > mbeans should also be fairly easy since I think this model is also close to > the mbean interceptor one. > > thanks > david --- 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
Re: [JBoss-dev] Proposal for jboss-wide interceptor framework
No No!! War War War!!! :-)) Actually I just wanted to get the discussion started early on and try to get people involved since I think it will be a big undertaking to convert all the interceptor models to a single one. I don't want to spring an entire system conversion on anyone without a lot of warning. I don't see how your proposed example is simple since I think it involves at least converting the remoting framework and probably the aop stuff. I was thinking of working in this order: mbeans remoting client interceptors ejb interceptors other. Aop could be converted at any time Bill agrees: I think this model is close enough to his that this conversion should be fairly easy. I think the main difference is the per-method interceptor stacks, which can probably be not used at first. mbeans should also be fairly easy since I think this model is also close to the mbean interceptor one. thanks david On 2003.03.02 14:36 Scott M Stark wrote: > Woa, before we have a full fledged interceptor war show up in main what > is the > status of the various JMX, AOP, etc interceptors and associated > frameworks? > It seems like several people are running around writing this without > demonstrating > how it applies to the existing services. A simple example is how do I > expose the > existing JNDI naming service via RMI/JRMP and RMI/HTTP with that ability > to introduce security and persistence? > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - Original Message - > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, March 02, 2003 10:28 AM > Subject: [JBoss-dev] Proposal for jboss-wide interceptor framework > > > > (resending, first attempt seems to have disappeared) > > > > I've committed a proposal for a jboss-wide interceptor framework in the > > common module under org.jboss.interception. This is based on Bill's > aop > > interceptor framework. It compiles but is untested. Several more or > less > > needed features are not yet implemented, such as a convenient way to > > supply a list of InterceptorFactories. > > > > The main differences, aside from coding style, are > > > > 1. I provide explicit support for changing the interceptor iterator as > a > > part of the invocation. For instance, this would be used when going > from > > the proxy-specific client interceptor chain to the transport specific > > interceptor chain, be reset upon deserialization by the server-side > > transport mechanism endpoint, and be reset when going from the > server-side > > transport specific interceptor chain to the e.g. ejb interceptor chain. > > > > 2. I provide explicit support for overridable interceptor specific > metadata > > set up by the InterceptorFactory. For instance, for an interceptor > that > > uses ejb xml metadata, the InterceptorFactory would process the xml > into a > > more appropriate form for use by the interceptor and store it in this > > metadata using the interceptor instance as a key. The interceptor can > then > > retrieve the metadata using itself as a key. I believe both Dain and I > > prototyped ejb interceptor implementations using this mechanism and > were > > pleased with the code simplifications that resulted. This metadata is > > stored in the InvocationFactory and supplied last to the list of > metadata > > resolvers in each invocation. This allows overriding by earlier > metadata > > in the list of resolvers. > > > > 3. I provide a framework for method (or field, etc etc) specific > > interceptor chains. The InvocationFactory maintains a map of keys to > > interceptor chains. The key will typically be the > method/field/whatever > > the invocation is for. The chains are constructed from a single list > of > > InterceptorFactories by supplying the key. If the interceptor is not > > needed for a particular key, the InterceptorFactory returns null. This > > > replaces the InterceptorFilterFactory interface. > > > > > > And finally a question... > > > > I think it would be more appropriate to have single level metadata > rather > > than the 2-level scheme Bill has implemented. The 2 level scheme can > be > > easily "recovered" by those interceptors that want it by storing a > > (single-level) SimpleMetaData object as the first level metadata > object. > > This would make it easier for interceptors to store individual custom > > objects as their metadata. > > > > I'd appreciate any and all comments especially if they are soon. If > there > > is no strong opposition I will start working to convert the remoting > > framework, client interceptors, and mbean interceptors to use this > > framework. > > > > Many thanks > > david jencks > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > ___ >
Re: [JBoss-dev] Proposal for jboss-wide interceptor framework
Woa, before we have a full fledged interceptor war show up in main what is the status of the various JMX, AOP, etc interceptors and associated frameworks? It seems like several people are running around writing this without demonstrating how it applies to the existing services. A simple example is how do I expose the existing JNDI naming service via RMI/JRMP and RMI/HTTP with that ability to introduce security and persistence? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, March 02, 2003 10:28 AM Subject: [JBoss-dev] Proposal for jboss-wide interceptor framework > (resending, first attempt seems to have disappeared) > > I've committed a proposal for a jboss-wide interceptor framework in the > common module under org.jboss.interception. This is based on Bill's aop > interceptor framework. It compiles but is untested. Several more or less > needed features are not yet implemented, such as a convenient way to > supply a list of InterceptorFactories. > > The main differences, aside from coding style, are > > 1. I provide explicit support for changing the interceptor iterator as a > part of the invocation. For instance, this would be used when going from > the proxy-specific client interceptor chain to the transport specific > interceptor chain, be reset upon deserialization by the server-side > transport mechanism endpoint, and be reset when going from the server-side > transport specific interceptor chain to the e.g. ejb interceptor chain. > > 2. I provide explicit support for overridable interceptor specific metadata > set up by the InterceptorFactory. For instance, for an interceptor that > uses ejb xml metadata, the InterceptorFactory would process the xml into a > more appropriate form for use by the interceptor and store it in this > metadata using the interceptor instance as a key. The interceptor can then > retrieve the metadata using itself as a key. I believe both Dain and I > prototyped ejb interceptor implementations using this mechanism and were > pleased with the code simplifications that resulted. This metadata is > stored in the InvocationFactory and supplied last to the list of metadata > resolvers in each invocation. This allows overriding by earlier metadata > in the list of resolvers. > > 3. I provide a framework for method (or field, etc etc) specific > interceptor chains. The InvocationFactory maintains a map of keys to > interceptor chains. The key will typically be the method/field/whatever > the invocation is for. The chains are constructed from a single list of > InterceptorFactories by supplying the key. If the interceptor is not > needed for a particular key, the InterceptorFactory returns null. This > replaces the InterceptorFilterFactory interface. > > > And finally a question... > > I think it would be more appropriate to have single level metadata rather > than the 2-level scheme Bill has implemented. The 2 level scheme can be > easily "recovered" by those interceptors that want it by storing a > (single-level) SimpleMetaData object as the first level metadata object. > This would make it easier for interceptors to store individual custom > objects as their metadata. > > I'd appreciate any and all comments especially if they are soon. If there > is no strong opposition I will start working to convert the remoting > framework, client interceptors, and mbean interceptors to use this > framework. > > Many thanks > david jencks > > > --- > 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 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
