"[...]which have different methods that can be called." This is a type problem. You can publish each service as a set of types. For example, following Stijn's example, publish the EpsonWF2530 as an EpsonPrinter and a Printer. Your consumers will now be able to do a "proper" type filtering, asking for an EpsonPrinter and call "epsonPrint" on it, if this is what they need.
Service properties are "ok" when you need a specific Printer with a certain implementation of print. It isn't a solution to the problem where you need a Printer with a method not in the API. In short, use types to encode type information. Service properties fall under "stringly typed solutions". Sometimes they are needed because the type system isn't expressive enough. Like the well known problem of storing dates as strings in JSON, because JSON has no date type. Going to the extreme, why not publish all services as "Object" and filter on "class=org.acme.MyClass". All that said, pragmatism is probably more worth than idealism. :) On Thu, Dec 19, 2013 at 11:26 AM, Stijn de Witt < [email protected]> wrote: > Let's say you have a service interface like this: > > interface Printer { > void print(); > } > > You could have multiple implementations (for different hardware): > > class ConsolePrinter implements Printer { > public void print() { > System.out.println("Hello World!"); > } > } > > class EpsonPrinter implements Printer ... > class CanonPrinter implements Printer ... > > Each implementation can be registered in the service registry on the same > interface, but with different OSGi service properties. Consumers can then > add a filter when querying the OSGi service registry to get the > implementations suitable for their purposes. E.G. by adding: > > (Printer-Brand=Epson) > > it could pick the EpsonPrinter without ever having to know that that > specific class exist. It only knows the interface and some properties to > filter on. > > -Stijn > > > -----Original Message----- > From: Neil Bartlett [mailto:[email protected]] > Sent: maandag 9 december 2013 14:02 > To: users > Subject: Re: Reflection > > The service interface represents the standard API. It is not necessary for > clients to use reflection to find the methods of the service: they are > compiled against the service interface. > > However at runtime, the service implementation can change... so long as it > provides the methods specified in the service interface. > > > On Mon, Dec 9, 2013 at 12:54 PM, Snorre Lothar von Gohren Edwin < > [email protected]> wrote: > > > Ok I see where you are going with this. > > But what if one have a standard api with different hardware types > > behind, which have different methods that can be called. > > Im having troubles in seeing how this can be done dynamically? > > > > > > On Mon, Dec 9, 2013 at 1:51 PM, Neil Bartlett <[email protected]> > > wrote: > > > > > On Mon, Dec 9, 2013 at 12:44 PM, Snorre Lothar von Gohren Edwin < > > > [email protected]> wrote: > > > > > > > Is reflection the way to go to handle a dynamic OSGi environment > > > > > > > > > No. > > > > > > > > > > or are > > > > there other customs or patterns to use? > > > > > > > > > > SERVICES! :-) > > > > > > > > > > In other words, is this heavily used in OSGi? > > > > > > > > > > No. > > > > > > > > > > > > > > -- > > > > Mvh > > > > Snorre Lothar von Gohren Edwin > > > > MeetMe: http://doodle.com/vonGohren > > > > +47 411 611 94 > > > > > > > > > > > > > > > -- > > Mvh > > Snorre Lothar von Gohren Edwin > > MeetMe: http://doodle.com/vonGohren > > +47 411 611 94 > > >
