"Java services api" == ServiceLoader I assume?
Going on that assumption:
No. ServiceLoader is just a discovery mechanism. There still needs to
be something that, as you say, negotiates amongst the various discovered
implementations of a particular service. 2 well known ServiceLoader
uses are JDBC drivers and image processors, each illustrating a
different approach that are really inherent to their respective problem
domains. In the case of JDBC drivers, the discovery is just used to
register all the available drivers; users must still specify which
driver they want via JDBC url protocol. In the case of image processing
(as I understand it anyway, not really my forte) the choice of processor
is more intrinsic to the image you ask to have processed based on MIME
type.
Here is sound like you more have the JDBC style, where discovery is just
making the complete set of possibilities known. The user would still
need to make a distinction. Or maybe you have some special rules like
(a) using the standard service if it is the only one discovered; (b)
using the "other" service if 2 are discovered; (c) requiring the user
tell you if 3 or more are found. Many ways to skin that cat.
On 10/12/2012 07:23 AM, 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.
>
> 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
st...@hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
