On 12 October 2012 14:13, Hardy Ferentschik <ha...@hibernate.org> wrote: > > On 12 Jan 2012, at 3:00 PM, Steve Ebersole wrote: > >> "Java services api" == ServiceLoader I assume? > > correct > >> 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. > > Right. I would expect the user to make this distinction via the configuration.
That's one way of doing it, but you can also avoid need for configuration properties if in different environments (Infinispan) you only have one implementation, which is different than the usual one. I really don't want to give a choice in that case ;) In other cases we might have multiple choices, but might still able to make the "right" choice without need of configuration, and maybe it's really not worth it to give an option. Of course there are cases in which you want to look at the configuration properties - that's why the SPI provides the properties - but reality is that this logic might be different depending on what service we're talking about. Consequentially, the ServiceManager itself doesn't deal with it but just creates a ServiceProvider for each need: this ServiceProvider implementation can use a selection choice as it makes most sense for its service on a case by case. > > I think really the problem is that what we have is actually not a > ServiceManager (at least not what I understand under this term). It is a > fancy way to instantiating a class and giving it a life cycle (aka #start(), > #stop()). > We really have more of a BeanLifeCycleManager. I see your point, but it doesn't really matter as we can't change this now: it's a widely used extension point. Let's see how it evolves during 5.0 work and then decide if it's worth changing names. Sanne > > --Hardy > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
