(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
