Hi Justin, That’s exactly where I was going with that analogy. The equivalent of service.ranking for plumbers would presumably be their Yelp rating. And if you have multiple plumbers all with 5-star reviews then just pick any, it doesn’t matter!
Neil > On 22 Jul 2017, at 14:04, Justin Edelson <jus...@justinedelson.com> wrote: > > Obviously you should pick the plumber with the highest service.ranking. > > Sorry, couldn't resist. > > On Sat, Jul 22, 2017 at 7:39 AM Neil Bartlett <njbartl...@gmail.com > <mailto:njbartl...@gmail.com>> wrote: > I'm not talking at all about multiple versions of the same jar. I'm talking > about multiple providers of the same service, possibly even from different > vendors. This happens just as easily under Service Loader as under OSGi. > > In your original email you asked: why does the consumer of PNG have to care > which PNG provider to choose. Well isn't that just a fact of life? I need a > plumber to fix my toilet... there are ten plumbers in my town, which should I > choose? Why do I have to care about plumbers?! > > Having choices can suck, but not as much as having no choice. > > Neil > > On 22 Jul 2017 10:44 am, "Mark Raynsford" <list+org.o...@io7m.com > <mailto:list%2borg.o...@io7m.com>> wrote: > On 2017-07-22T00:22:31 +0100 > Neil Bartlett <njbartl...@gmail.com <mailto:njbartl...@gmail.com>> wrote: > > > Hello Mark, > > 'Ello. > > > > > Tell me, why is this problem any harder under OSGi than with > > ServiceLoader?? In both cases, anybody can install a bundle or a JAR that > > provides a service with a name, and those names can collide. > > In Java < 9, it's not so much that it can't happen, but more that > having two different versions of the same jar file on the classpath is > considered a mistake, and build tools like Maven will (via the Enforcer > plugin) try to prevent that from happening. In Java 9, it's explicitly > an error for two modular jars in the same ModuleLayer to export the > same package, so the program won't even start up if you try it. In > OSGi, having multiple versions of a bundle installed and running is not > considered an error (although it's probably not exactly encouraged > either), so the hypothetical ImageFormats class that tracks providers > by name would give inconsistent results in that situation. > > > In both ServiceLoader and OSGi there is a simple rule for selecting a > > single instance of a service where many are available. Under ServiceLoader > > it is just the first JAR on the classpath. With OSGi you can attach a > > service.ranking property to any service. This can be done by the developer > > of the service, or supplied/overridden at runtime using Config Admin. Note > > that even with service.ranking, it is possible to have multiple service > > with the same high ranking. In this case OSGi picks the service with the > > lowest service.id <http://service.id/>, which in effect usually means the > > one that was registered first. > > Yes, I'm aware. As I mentioned in the other message to this list, using > the service ranking and ID would *probably* be fine given a very > long-running framework instance, because the ordering of service.id > <http://service.id/> will > most likely reflect the order in which a given set of bundle versions > were installed. However, if you start up a new framework instance with > a set of bundles already in the bundle cache, there's nothing that > guarantees that the older bundle versions will get lower service IDs, > right? > > > By the way it is generally bad practice to provide a service name via a > > method on the service interface. Better to add this as a property to the > > service metadata, so that it can be selected using declarative filters. For > > example: > > > > @Component(property = “name=JPEG”) > > public class JPEGImageFormat implements ImageFormat { … } > > > > @Component > > public class PaintProgram { > > @Reference(target = “(name=JPEG)”) > > ImageFormat formatter; > > // ... > > } > > I'd tend to agree, but I did make this point: > > > Sometimes, though, a class analogous to ImageFormats > > is necessary, particularly when you expect callers to be OSGi-unaware > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > and/or you only have very simple selection criteria (like a "PNG" > > string). > > In other words, if you're writing code that is expected to work both > when running in an OSGi framework and when running on the classpath or > module path, you may want/need to abstract over the registration of > ImageFormats. In other words, you might want to provide a hypothetical > ImageFormatRegistry interface that _both OSGi and non-OSGi consumers_ > can make calls into to find image formats (to avoid having to write > one code path for OSGi, and one code path for everyone else). Outside of > OSGi, the best-practice rules for Java < 9 make multiple registrations > of an ImageFormat less likely. The strict Java 9 rules regarding > conflicting package exports make multiple registrations impossible, at > least when those registrations come from two different versions of the > same modular jar. In an OSGi framework, however, the situation is > slightly more permissive than the Java < 9 case; multiple installed > versions of a bundle are a reality, and complicate the implementation of > ImageFormatRegistry class. > > -- > Mark Raynsford | http://www.io7m.com <http://www.io7m.com/> > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <https://mail.osgi.org/mailman/listinfo/osgi-dev>_______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
