This is an interesting idea; I'll take a peek when I get the chance. Some other ideas I've considered:
a) Defining interceptor "sets" and identify one or more sets for a service. This is more of a "drag in" approach than a "push in" approach you described. b) Having a "hivemind.InterceptorConsultant" service that would be hooked into the code that constructs the interceptor stack. The consultant acts as a delegate to the ServiceExtensionPoint, and can provide additional interceptors to the normal list. The InterceptorConsultant could be driven off of an extension point and could achieve something very similar to what you've described. I've also through about: 1) A mechanism to allow you to enable/disable a contributed interceptor at runtime, perhaps driven off of system properties. 2) Passing parameters to interceptor factories in the same way that we do to ImplementationFactories. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com > -----Original Message----- > From: Christian Essl [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 21, 2003 1:58 PM > To: [EMAIL PROTECTED] > Subject: [HiveMind] Proposal for adding Interceptors to a set > of Services > > > > > I'd like to propose a module level tag, with which it is possible to > register Interceptors with all in the Registry Services or > all Services > which implement a (some) certain interface(s). I've > implemented a proposal > for this feature and tested it - the diff is attached. > > These 'global-interceptors' have some advantages. Ie it would > be possible > to register (unregister) a Logger for all Services with just a little > change to just one module. Also services implementing a > certain interface > could be given automatically parameters through such an Interceptor > (Avalon like) without the need to specify the interceptor in > each service. > This therefore also reduces the amount of failure because of > forgetting the > interceptor. The same way a stop-service could be implemented, which > informs all loaded Services that implement iE StopInterface when the > program exits. > > For the code of my proposal I have changed the module xml > format to include > under <module> the following tag: > > <global-interceptor service-id="id of ServiceInterceptorFactory" > order="interceptor-order"> > <class name="full.interface.name"/> > <class name="full.interface.name2"/> </global-interceptor> > > The global-interceptor tag takes the same arguments as the > <interceptor> > tag. If no <class> tag is specified the interceptor will be > registered with > all Services in all modules. If there are one ore more > <class> tags the > Services which are intercepted must implement all the given > interface(s) > (AND). If there are more <global-interceptor>s with the same > ServiceInterceptorFactory-Id than the Interceptor is wrapped > if at least > one fits (OR) > > The ServiceInterceptorFactories specified and the Services > requested of the > Factory at creation time are never wrapped by global > Interceptors (because > of circularity - actually the implementation loads all the > ServiceInterceptorFactories in > RegistryBuilder.constructRegistry() as non > deferred). > > My implementation works following: First the DescriptorParser > builds up > GlobalInterceptorDescriptors which are added to the ModuleDescriptor. > > In the RegistryBuilder one instance of > org....hivemind.impl.GlobalInterceptorRegistry is build up from the > Descriptors. There is only one instance - held in an field - per > RegistryBuilder (and so per Registry). This instance is used > to hold all > the mappings of interfaces to > ServiceInterceptorContributions. The instance > is given to each ServiceExtensionPointImpl when it is > constructed. The > point will use the instance in addInterceptors() to request > the global- > mapped Interceptors for itself and add it to it's own > interceptors list. > > When the Modules are processed in the RegistryBuilder the > GlobalInterceptorRegistry is populated but not yet ready to > use. As the > last step in the RegistryBuilder.constructRegistry() the > GlobalInterceptorRegistry is build up. Here some > optimizations are done (or > better could be done) and all the needed > ServiceInterceptorFactories are > loaded - non deffered. Till this time the > ServiceExtensionPointImpls will > not use the GlobalInterceptorRegistry. This way Services (the > ServiceInterceptorFactories and there requested Services) > loaded by the > GlobalInterceptorRegistry itself are not intercepted (except > if defined in > a Service-Extension), which is important for circularity. > After this the > GlobalInterceptorRegister is ready to be used by the > ServiceExtesionPointImpls and all Service loaded are wrapped > if they match. > > Finally there are also two Tests which you can see from the diff. > > -- > Using M2, Opera's revolutionary e-mail client: > http://www.opera.com/m2/ > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
