No No!! War War War!!! :-))
Actually I just wanted to get the discussion started early on and try to get people involved since I think it will be a big undertaking to convert all the interceptor models to a single one. I don't want to spring an entire system conversion on anyone without a lot of warning. I don't see how your proposed example is simple since I think it involves at least converting the remoting framework and probably the aop stuff. I was thinking of working in this order: mbeans remoting client interceptors ejb interceptors other. Aop could be converted at any time Bill agrees: I think this model is close enough to his that this conversion should be fairly easy. I think the main difference is the per-method interceptor stacks, which can probably be not used at first. mbeans should also be fairly easy since I think this model is also close to the mbean interceptor one. thanks david On 2003.03.02 14:36 Scott M Stark wrote: > 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 > > ----- Original Message ----- > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, March 02, 2003 10:28 AM > Subject: [JBoss-dev] Proposal for jboss-wide interceptor framework > > > > (resending, first attempt seems to have disappeared) > > > > I've committed a proposal for a jboss-wide interceptor framework in the > > common module under org.jboss.interception. This is based on Bill's > aop > > interceptor framework. It compiles but is untested. Several more or > less > > needed features are not yet implemented, such as a convenient way to > > supply a list of InterceptorFactories. > > > > The main differences, aside from coding style, are > > > > 1. I provide explicit support for changing the interceptor iterator as > a > > part of the invocation. For instance, this would be used when going > from > > the proxy-specific client interceptor chain to the transport specific > > interceptor chain, be reset upon deserialization by the server-side > > transport mechanism endpoint, and be reset when going from the > server-side > > transport specific interceptor chain to the e.g. ejb interceptor chain. > > > > 2. I provide explicit support for overridable interceptor specific > metadata > > set up by the InterceptorFactory. For instance, for an interceptor > that > > uses ejb xml metadata, the InterceptorFactory would process the xml > into a > > more appropriate form for use by the interceptor and store it in this > > metadata using the interceptor instance as a key. The interceptor can > then > > retrieve the metadata using itself as a key. I believe both Dain and I > > prototyped ejb interceptor implementations using this mechanism and > were > > pleased with the code simplifications that resulted. This metadata is > > stored in the InvocationFactory and supplied last to the list of > metadata > > resolvers in each invocation. This allows overriding by earlier > metadata > > in the list of resolvers. > > > > 3. I provide a framework for method (or field, etc etc) specific > > interceptor chains. The InvocationFactory maintains a map of keys to > > interceptor chains. The key will typically be the > method/field/whatever > > the invocation is for. The chains are constructed from a single list > of > > InterceptorFactories by supplying the key. If the interceptor is not > > needed for a particular key, the InterceptorFactory returns null. This > > > replaces the InterceptorFilterFactory interface. > > > > > > And finally a question... > > > > I think it would be more appropriate to have single level metadata > rather > > than the 2-level scheme Bill has implemented. The 2 level scheme can > be > > easily "recovered" by those interceptors that want it by storing a > > (single-level) SimpleMetaData object as the first level metadata > object. > > This would make it easier for interceptors to store individual custom > > objects as their metadata. > > > > I'd appreciate any and all comments especially if they are soon. If > there > > is no strong opposition I will start working to convert the remoting > > framework, client interceptors, and mbean interceptors to use this > > framework. > > > > Many 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: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
