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 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. well, we now have about 2 implementations, the ejb one and the remoting framework one. I think the remoting framework one has a lot more features and I thought we basically agreed to use it. So the work is figuring out how to use ejbs with it. 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. If I understand you correctly this is the means by which the server side transport layer figures out what to call, currently implemented as sort of an mbean lookup in a proprietary hashmap for ejbs? Personally I don't see a strong reason not to continue to use mbeans for all our targets, I haven't seen or understood the arguments why this is not adequate. However, if we have a server side transport interceptor stack, this decision will be made by the last interceptor, therefore it will be completely pluggable. We could use something like the proposed multiple interceptor chain facility (5 above) to select a server side transport layer interceptor chain based on metadata in the deserialized invocation. This would let us send invocations using various different target selection methods over the same e.g. socket. Thanks david > > > 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 > > ------------------------------------------------------- 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
