commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Essl <christiane...@yahoo.de>
Subject [HiveMind] Proposal for adding Interceptors to a set of Services
Date Thu, 21 Aug 2003 17:58:07 GMT


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/
Mime
View raw message