Hi David L, Well, I have to say that I've always thought that the Converter should be a service as well, but where services really come to shine is where you potentially have different implementations that might provide different features. For the Converter there is very little room for difference in implementations. The converters should behave exactly like the spec will describe. Any variation on that can be added via the adapters. There is still the possibility of distinguishing between implementations from a performance point of view, but from a behavioural point of view all converters should behave the same to that they are entirely predictable. Of course, this is still possible to do with services, and there are many services already of which you would only typically have one at runtime.
The difference here is that the converter is such a generally useful thing, that it can also be really useful outside of an OSGi framework. The API itself has no dependency on any other OSGi classes. The thinking is that with a simple constructor this makes the converter really easy to use in any environment Java environment. Services are still one of the best features of OSGi IMHO, and for the Serializers (what used to be called Codecs) we'll still use services. This especially makes sense since there can be more than one Serializer, there is a lot of implementation freedom there (can support any kind of format you like) and they are selected based on service properties. So I agree, services are generally the best choice, however in some specific cases, using a simple constructor (or factory method) can make sense, especially if there is little room for variation. Cheers, David On 8 September 2016 at 16:42, David Leangen <o...@leangen.net> wrote: > > 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 > >>>> > >>> > >> > >
