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> 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> wrote:
>
>> On 2017-07-22T00:22:31 +0100
>> Neil Bartlett <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, 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 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
>>
> _______________________________________________
> 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
