> -----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? > > 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
