Yes I understand. Thank you On Sep 8, 2016 7:10 PM, "David Bosschaert" <david.bosscha...@gmail.com> wrote:
> 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 > > > > > >
