Hi David D, The pattern that is being followed here is similar to what is done for OSGi Promises of which an implementation exists in Apache Aries [1]. There the Deferred, a class in the org.osgi.service... namespace instantiates the Aries implementation. Other implementations can replace the Deferred class to instantiate their own implementations. Similarly here constructing a new org.osgi.service.converter.StandardConverter will instantiate the Felix implementation. The org.osgi.service.converter package is embedded in the bundle. Other implementations will also embed the org.osgi.service.converter package but provide a different StandardConverter class, which instantiates a different implementation.
Changed in the recent refactoring is that the Converter is not a service any more. The StandardConverter is a converter instance that is exactly doing what it says in the spec. Anyone who wants a converter simply creates one by calling new StandardConverter(). If you want to add customization rules, you simply obtain an Adapter by calling Adapter a = new StandardConverter().newAdapter(); Then you can add your rules to a. The Adapter a is also a Converter - it implements the Converter interface just like the StandardConverter. So you can call a.convert(something).to(SomethingElse.class) which triggers your rules if applicable. This allows you to create different adapters for different parts of your application. Its up to the application to decide how to share these adapters with other parts of the application. You could use the service registry for that but that's up to you. Hope this helps, David [1] see https://svn.apache.org/viewvc/aries/trunk/async/ promise-api/src/main/java/org/osgi/util/promise/Deferred.java?view=markup On 8 September 2016 at 07:00, David Daniel <david.daniel.1...@gmail.com> wrote: > I am guessing the stuff in the org.osgi.service namespace is going into a > separate bundle similar to how the other services were taken out of > compendium. Right now the StandardConverter in source control news up an > apache impl converter object. Is that code going to change to get a > converterfactory from the service registry and get a converter instance > from there or something like that. The reason I am asking is that right > now I have different bundles that add rules to the adapter for the objects > that they manage. It happens one time on activate. Should I be changing > how I do things for instance, should my "Search" service have a function > that gets a converter with the rules added and inside the get converter > function it news up a standard converter and then adds the rules or should > I be adding rules to some global service or adapter that StandardConverter > will eventually get an object from. > > Thanks for any help, > David Daniel > > On Thu, Sep 8, 2016 at 9:30 AM, David Bosschaert < > david.bosscha...@gmail.com > > wrote: > > > Hi all, > > > > The Converter API was recently discussed in the OSGi Expert Groups and > > based on the feedback the API has been refactored a bit. > > One change is how the converter is obtained in a standard way. Previously > > this was done by calling ConverterFactory.standardConverter() but this > is > > now done by calling 'new StandardConverter()'. > > The converter can be used inside an OSGi framework but also outside of > OSGi > > in the same way. This follows a pattern used by the OSGi Promises as > well. > > The Codecs will remain an OSGi service (also obtainable via > > ServiceLoader.load()) but they are renamed to 'Serializer'. > > I've made these changes to the Felix Converter codebase. > > > > This is a component that is still very much under development until the > > OSGi R7 specs are released so changes like this can happen. For those who > > already use the convert it should not be too hard to update their code - > > hopefully :) > > > > Cheers, > > > > David > > >
