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? > > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > > > > ------------------------------------------------------- > 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
