felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Leangen <o...@leangen.net>
Subject Re: [Converter] Change in API for obtaining a Converter
Date Thu, 08 Sep 2016 23:42:45 GMT


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…


> On Sep 9, 2016, at 8:14 AM, David Daniel <david.daniel.1979@gmail.com> wrote:
> Yes I understand. Thank you
> On Sep 8, 2016 7:10 PM, "David Bosschaert" <david.bosschaert@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.1979@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.bosschaert@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

View raw message