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