[hibernate-dev] [HSearch] ServiceManager and services

[Emmanuel Bernard]

On Fri 2012-10-12 14:23, Hardy Ferentschik wrote:
> Hi,
> 
> as part of my investigations for HSEARCH-1025 and HSEARCH-1026 I had a look at how services are implemented in Search.
> I thought I could make the statistics collector also a service. Looking at the code I am a little confused though.
> 
> Let's look at the different pieces.
> 
> First ServiceManager:
> 
> public interface ServiceManager {
> 
> 	public abstract <T> T requestService(Class<? extends ServiceProvider<T>> serviceProviderClass, BuildContext context);
> 
> 	public abstract void releaseService(Class<? extends ServiceProvider<?>> serviceProviderClass);
> 
> 	public abstract void stopServices();
> 
> }
> 
> And now one service example:
> 
> public class JGroupsChannelProvider implements ServiceProvider<MessageSender> {
> …
> }
> 
> And one usage:
> 
> this.messageSender = serviceManager.requestService( JGroupsChannelProvider.class, context );
> 
> Now, I am wondering how this is a configurable service implementation. Whenever I request a "service" I specify a concrete implementation.
> How is that different to hard coded things or using some properties to specify the impl class. Really the service in the above case is the interface
> MessageSender and that's what I should request as a service. 

We did not have the goal to offer an abstraction between a contract and
its implementation. Our goal was to have services that are not started
unless they are really requested. JGroups is not always used for
example. Likewise the Infinispan CacheManagerServiceProvider is only
used when you configure an Infinispan backend.

> Which leads me to the second point, the service discovery. For that we use META-INF/services/org.hibernate.search.spi.ServiceProvider where we list
> the ServiceProvider implementation we use. How, could I as user e.g. replace the serialization service to use something else than Avro? 

Well you cannot replace Avro for many reasons but if we were to make the
serialization layer customizable, we would use the same kind of strategy
we use for the backend: A specific property accepting fqcn with shortcuts
for the main implementations.
We would not use the service provider approach.