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. --Hardy _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
