[hibernate-dev] [HSearch] ServiceManager and services

[Sanne Grinovero]

Hi Hardy,
I was having similar doubts when recently converted the Serializer
service to a Service.

The ServiceProvider<T> can contain logic to make a choice about which
Service implementation you're supposed to get, as it receives the
configuration properties.

In short how different alternatives are discovered, that's not
something the ServiceProvider specifies, you have a lot of freedom in
that sense: the Provider can define whatever logic it wants; you're
supposed to have a single provider, but this one can be overriden by
other modules. Then the overriden Provider can decide which Service
implementor to return.

Example: JGroupsChannelProvider has a start() method in which it
decides what exactly it's going to create.

I agree it could do better, for example by listing alternative
implementations for the Provider to choose from, but until we don't
need that there's no reason to over engineer it.

The current reasons to have it are:
 - lifecycle management start/stop of services
 - capability to override one when started programmatically from the
configuration instance (provided services - think Infinispan Query vs.
Hibernate Search ORM might need a different way to do thing)
 - make sure the different users of a service can share a unique instance

It's likely that this will evolve; especially the Avro picking stuff
you mention.. doesn't look like we finished that; in fact there is a
TODO in SerializationProviderService. I'll check JIRA to see if we're
tracking that.

Cheers,
Sanne


On 12 October 2012 13:23, Hardy Ferentschik <hardy at hibernate.org> 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.
>
> 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?
> I guess in this case the user adds to its jar also META-INF/services/org.hibernate.search.spi.ServiceProvider specifying his implementation class, but
> then there must be some code which negotiates which implementation to chose, right? That's how I would expect it to work using the Java services api.
>
> Or maybe ServiceManager is not what I think a ServiceManager should be!?
> What am I missing?
>
> --Hardy
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev