On Fri 2012-10-12 15:13, Hardy Ferentschik 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. > > 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.
Basically for you a Service must allow for multiple implementations and a ServiceManager must offer a way to switch between various implementations. To me a Service renders a... service. In Hibernate Search services are lazy loaded and we have the notion of ServiceProvider to cope with that. We also happen to have a way to chose between one implementation vs another via configuration (see backends, optimization strategies etc). I don't see how renaming this class a BeanLifeCycleManager makes any of this better. AFAIK the only beans that have lifecycles are managed bean, CDI beans or Enterprise JavaBeans. None of them mandate an interface / implementation split and they don't carry the idea of pluggable implementations necessarily. Emmanuel _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
