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
