Hi, Just out of pure curiosity… what is the reason for moving away from services like this? This seems like quite a departure from the way things used to be done…
Cheers, =David > On Sep 9, 2016, at 8:14 AM, David Daniel <david.daniel.1...@gmail.com> wrote: > > 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 >>>> >>> >>
