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