[hibernate-dev] [HSearch] ServiceManager and services

[Sanne Grinovero]

On 12 October 2012 13:55, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 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.

What you say makes sense, but why to we have an
JavaSerializationSerializationProvider then?
It's an alternative implementation which is not using Avro.

AFAIK there currently is no way to select that one, hence the TODO I
had added recently.