You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by David Bosschaert <da...@gmail.com> on 2016/09/08 13:30:07 UTC
[Converter] Change in API for obtaining a Converter
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
Re: [Converter] Change in API for obtaining a Converter
Posted by David Bosschaert <da...@gmail.com>.
Some more comments inline.
On 8 September 2016 at 20:00, David Leangen <os...@leangen.net> wrote:
> “new” (or static) for non OSGi code, the usual service acquisition for
> OSGi environments. The basic idea was to separate API from Implementation.
> Is that no longer the objective?
>
I can definitely see this point but whether you use a factory method
org.osgi.converter.ConverterFactory.standardConverter() or new
org.osgi.converter.StandardConverter() you would still have to replace one
class in the API. You can avoid this by using the ServiceLoader or by using
OSGi Services but in this case the feedback received was that just doing
'new StandardConverter()' is nice and simple. There are other places in the
OSGi specs where this is done this way too, the Deferred class in the
Promises API is an example [1] [2].
> Or, if things start to get messy, OSGi only? Why the sudden desire to take
> a turn away from OSGi?
>
We're not turning away from OSGi at all, but most of the specifications
that OSGi defines have some dependencies on other OSGi APIs or the services
model. So they don't make much sense without a framework. The converter
started out as a service but since it really has no dependency on any other
OSGi API and seems to be a very useful thing in general the desire was to
make it useable in any kind of context.
>
> Or maybe this project should not even be part of OSGi?
>
The main benefit of it being part of OSGi is that it is goes through the
whole specification process. This means that it will go through the
scrutiny of many people, OSGi members and non-members, there will be a
Conformance Test Suite and a spec document in the end. This is a valuable
thing to do to ensure that it can do what everybody needs, ensure quality
and most importantly portability.
>
> I just find it a bit confusing. Am I missing something? Maybe OSGi is
> starting to lose its way??
>
>
I certainly hope not. I will definitely bring your feedback to the
discussion at OSGi, and to be honest, I had similar feedback myself. One of
the main goals in OSGi is to have patterns that are common across the API.
The Promises API, which also can be used outside of a framework, uses this
mechanism to obtain an instance so the thinking is that this API should
follow the same pattern.
Cheers,
David
[1]
https://osgi.org/javadoc/r6/enterprise/org/osgi/util/promise/Deferred.html
[2]
https://svn.apache.org/viewvc/aries/trunk/async/promise-api/src/main/java/org/osgi/util/promise/Deferred.java?view=markup
Re: [Converter] Change in API for obtaining a Converter
Posted by David Bosschaert <da...@gmail.com>.
Hi David D,
The problem with registering Rule objects in the Service Registry is that
it becomes a bit hard to create different adapters for different parts of
the code. Maybe in bundle A you need a converter adapter that has rules X
and Y and in bundle B and C you need a converter adapter that has rules Y
and Z. It kind of becomes messy to specify what rules need to be picked up
by what converter if we used a whiteboard pattern for the Adapter rules.
On the other hand I think it would be totally fine to create your Converter
adapter somewhere based on the rules you want and then put your adapted
Converters in the OSGi service registry with the properties that you define
to share these adapters. Then in your consuming bundles you can select the
right adapted Converter by using the right filter. I think that there is
absolutely nothing 'non-standard' in that approach as you can use the
Service Registry to share whatever objects you like. When you need the
spec-defined converter you create a new one by calling 'new
StandardConverter()' so there is a clear way to obtain a plain vanilla one
versus the adapted ones.
If you want to share rules across adapted converters you can do this by
creating specific MyRule() classes that provide a single place to hold the
rule implementations. Or you could register those Rules in the SR yourself
and consume them when creating your own adapters - but then you need to
make sure to select the right ones as mentioned above.
Hope this helps/makes sense,
David
BTW this is exactly the kinds of discussions we like to have in the OSGi
Expert Groups, so if you, or anyone else reading this is actually
interested in taking part in these at OSGi, feel free to join the
organization: http://www.osgi.org/join
On 9 September 2016 at 07:01, David Daniel <da...@gmail.com>
wrote:
> Sorry, I meant Rule and not FunctionThrowsException
>
> On Fri, Sep 9, 2016 at 9:47 AM, David Daniel <da...@gmail.com>
> wrote:
>
> > For me I don't think it is the change to new that is concerning but I am
> > also concerned with the departure from the OSGI dependencies and way of
> > doing things. I would prefer an implementation that does something like
> > includes FunctionThrowsException from a whiteboard pattern with a
> prototype
> > scope to determine the standard rules in the felix implementation (I can
> > understand why you are not doing this in the current implementation
> because
> > then it be dependent on osgi). I can see how I can expose a converter
> as a
> > service and add the rules I want but it would not be very standard.
> > Libraries that I use for stuff like rest or something else would not use
> my
> > converter service. If I wanted libraries to use my converter
> > implementation I would have to write my own custom converter bundle but
> > then I would lose out on having a well tested bundle that is used in many
> > applications. I can understand the new route but I personally prefer the
> > old one and am a fan of OSGI.
> >
> > David Daniel
> >
> > On Thu, Sep 8, 2016 at 11:00 PM, David Leangen <os...@leangen.net> wrote:
> >
> >>
> >> :-)
> >>
> >> “new” (or static) for non OSGi code, the usual service acquisition for
> >> OSGi environments. The basic idea was to separate API from
> Implementation.
> >> Is that no longer the objective?
> >>
> >> Or, if things start to get messy, OSGi only? Why the sudden desire to
> >> take a turn away from OSGi?
> >>
> >> Or maybe this project should not even be part of OSGi?
> >>
> >> I just find it a bit confusing. Am I missing something? Maybe OSGi is
> >> starting to lose its way??
> >>
> >> Cheers,
> >> =David
> >>
> >>
> >> > On Sep 9, 2016, at 11:51 AM, Benson Margulies <bi...@gmail.com>
> >> wrote:
> >> >
> >> > And then you need 'new' for the Factory, or a static method?
> Somewhere,
> >> the
> >> > chain of abstraction has to stop. If you don't have any parameters
> that
> >> > modify the creation, 'new' is just as good as any sort of Factory or
> >> > Builder.
> >> >
> >> > On Thu, Sep 8, 2016 at 10:21 PM, David Leangen <os...@leangen.net>
> >> wrote:
> >> >
> >> >>
> >> >> Hi David B.,
> >> >>
> >> >> Thank for your this explanation. Much of this makes sense, but again,
> >> just
> >> >> out of curiosity…
> >> >>
> >> >> I do understand the benefit of having this type of functionality
> >> outside
> >> >> of an OSGi environment. Perhaps the same could even be said for many
> >> other
> >> >> services, too, I’m not sure.
> >> >>
> >> >> To do that, instead of using “new” (which for me is a bit of a
> shock; I
> >> >> don’t recall even having used “new” to obtain a “service” from a
> >> different
> >> >> bundle), why not use a factory? Actually, the previous way that you
> >> wrote
> >> >> the util package with the publicly available Factory seems like a
> good
> >> >> approach to me.
> >> >>
> >> >> I’m not married to it, I’m just trying to understand why… Why is
> “new”
> >> >> better than a factory, if both achieve the same objective?
> >> >>
> >> >>
> >> >> Cheers,
> >> >> =David
> >> >>
> >> >>
> >> >>
> >> >>> On Sep 9, 2016, at 9:53 AM, David Bosschaert <
> >> david.bosschaert@gmail.com>
> >> >> wrote:
> >> >>>
> >> >>> 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 <os...@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.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
> >> >>>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>
> >> >>>>
> >> >>
> >> >>
> >>
> >>
> >
>
Re: [Converter] Change in API for obtaining a Converter
Posted by David Daniel <da...@gmail.com>.
Sorry, I meant Rule and not FunctionThrowsException
On Fri, Sep 9, 2016 at 9:47 AM, David Daniel <da...@gmail.com>
wrote:
> For me I don't think it is the change to new that is concerning but I am
> also concerned with the departure from the OSGI dependencies and way of
> doing things. I would prefer an implementation that does something like
> includes FunctionThrowsException from a whiteboard pattern with a prototype
> scope to determine the standard rules in the felix implementation (I can
> understand why you are not doing this in the current implementation because
> then it be dependent on osgi). I can see how I can expose a converter as a
> service and add the rules I want but it would not be very standard.
> Libraries that I use for stuff like rest or something else would not use my
> converter service. If I wanted libraries to use my converter
> implementation I would have to write my own custom converter bundle but
> then I would lose out on having a well tested bundle that is used in many
> applications. I can understand the new route but I personally prefer the
> old one and am a fan of OSGI.
>
> David Daniel
>
> On Thu, Sep 8, 2016 at 11:00 PM, David Leangen <os...@leangen.net> wrote:
>
>>
>> :-)
>>
>> “new” (or static) for non OSGi code, the usual service acquisition for
>> OSGi environments. The basic idea was to separate API from Implementation.
>> Is that no longer the objective?
>>
>> Or, if things start to get messy, OSGi only? Why the sudden desire to
>> take a turn away from OSGi?
>>
>> Or maybe this project should not even be part of OSGi?
>>
>> I just find it a bit confusing. Am I missing something? Maybe OSGi is
>> starting to lose its way??
>>
>> Cheers,
>> =David
>>
>>
>> > On Sep 9, 2016, at 11:51 AM, Benson Margulies <bi...@gmail.com>
>> wrote:
>> >
>> > And then you need 'new' for the Factory, or a static method? Somewhere,
>> the
>> > chain of abstraction has to stop. If you don't have any parameters that
>> > modify the creation, 'new' is just as good as any sort of Factory or
>> > Builder.
>> >
>> > On Thu, Sep 8, 2016 at 10:21 PM, David Leangen <os...@leangen.net>
>> wrote:
>> >
>> >>
>> >> Hi David B.,
>> >>
>> >> Thank for your this explanation. Much of this makes sense, but again,
>> just
>> >> out of curiosity…
>> >>
>> >> I do understand the benefit of having this type of functionality
>> outside
>> >> of an OSGi environment. Perhaps the same could even be said for many
>> other
>> >> services, too, I’m not sure.
>> >>
>> >> To do that, instead of using “new” (which for me is a bit of a shock; I
>> >> don’t recall even having used “new” to obtain a “service” from a
>> different
>> >> bundle), why not use a factory? Actually, the previous way that you
>> wrote
>> >> the util package with the publicly available Factory seems like a good
>> >> approach to me.
>> >>
>> >> I’m not married to it, I’m just trying to understand why… Why is “new”
>> >> better than a factory, if both achieve the same objective?
>> >>
>> >>
>> >> Cheers,
>> >> =David
>> >>
>> >>
>> >>
>> >>> On Sep 9, 2016, at 9:53 AM, David Bosschaert <
>> david.bosschaert@gmail.com>
>> >> wrote:
>> >>>
>> >>> 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 <os...@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.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
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >>
>> >>
>>
>>
>
Re: [Converter] Change in API for obtaining a Converter
Posted by David Daniel <da...@gmail.com>.
For me I don't think it is the change to new that is concerning but I am
also concerned with the departure from the OSGI dependencies and way of
doing things. I would prefer an implementation that does something like
includes FunctionThrowsException from a whiteboard pattern with a prototype
scope to determine the standard rules in the felix implementation (I can
understand why you are not doing this in the current implementation because
then it be dependent on osgi). I can see how I can expose a converter as a
service and add the rules I want but it would not be very standard.
Libraries that I use for stuff like rest or something else would not use my
converter service. If I wanted libraries to use my converter
implementation I would have to write my own custom converter bundle but
then I would lose out on having a well tested bundle that is used in many
applications. I can understand the new route but I personally prefer the
old one and am a fan of OSGI.
David Daniel
On Thu, Sep 8, 2016 at 11:00 PM, David Leangen <os...@leangen.net> wrote:
>
> :-)
>
> “new” (or static) for non OSGi code, the usual service acquisition for
> OSGi environments. The basic idea was to separate API from Implementation.
> Is that no longer the objective?
>
> Or, if things start to get messy, OSGi only? Why the sudden desire to take
> a turn away from OSGi?
>
> Or maybe this project should not even be part of OSGi?
>
> I just find it a bit confusing. Am I missing something? Maybe OSGi is
> starting to lose its way??
>
> Cheers,
> =David
>
>
> > On Sep 9, 2016, at 11:51 AM, Benson Margulies <bi...@gmail.com>
> wrote:
> >
> > And then you need 'new' for the Factory, or a static method? Somewhere,
> the
> > chain of abstraction has to stop. If you don't have any parameters that
> > modify the creation, 'new' is just as good as any sort of Factory or
> > Builder.
> >
> > On Thu, Sep 8, 2016 at 10:21 PM, David Leangen <os...@leangen.net> wrote:
> >
> >>
> >> Hi David B.,
> >>
> >> Thank for your this explanation. Much of this makes sense, but again,
> just
> >> out of curiosity…
> >>
> >> I do understand the benefit of having this type of functionality outside
> >> of an OSGi environment. Perhaps the same could even be said for many
> other
> >> services, too, I’m not sure.
> >>
> >> To do that, instead of using “new” (which for me is a bit of a shock; I
> >> don’t recall even having used “new” to obtain a “service” from a
> different
> >> bundle), why not use a factory? Actually, the previous way that you
> wrote
> >> the util package with the publicly available Factory seems like a good
> >> approach to me.
> >>
> >> I’m not married to it, I’m just trying to understand why… Why is “new”
> >> better than a factory, if both achieve the same objective?
> >>
> >>
> >> Cheers,
> >> =David
> >>
> >>
> >>
> >>> On Sep 9, 2016, at 9:53 AM, David Bosschaert <
> david.bosschaert@gmail.com>
> >> wrote:
> >>>
> >>> 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 <os...@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.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
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: [Converter] Change in API for obtaining a Converter
Posted by David Leangen <os...@leangen.net>.
:-)
“new” (or static) for non OSGi code, the usual service acquisition for OSGi environments. The basic idea was to separate API from Implementation. Is that no longer the objective?
Or, if things start to get messy, OSGi only? Why the sudden desire to take a turn away from OSGi?
Or maybe this project should not even be part of OSGi?
I just find it a bit confusing. Am I missing something? Maybe OSGi is starting to lose its way??
Cheers,
=David
> On Sep 9, 2016, at 11:51 AM, Benson Margulies <bi...@gmail.com> wrote:
>
> And then you need 'new' for the Factory, or a static method? Somewhere, the
> chain of abstraction has to stop. If you don't have any parameters that
> modify the creation, 'new' is just as good as any sort of Factory or
> Builder.
>
> On Thu, Sep 8, 2016 at 10:21 PM, David Leangen <os...@leangen.net> wrote:
>
>>
>> Hi David B.,
>>
>> Thank for your this explanation. Much of this makes sense, but again, just
>> out of curiosity…
>>
>> I do understand the benefit of having this type of functionality outside
>> of an OSGi environment. Perhaps the same could even be said for many other
>> services, too, I’m not sure.
>>
>> To do that, instead of using “new” (which for me is a bit of a shock; I
>> don’t recall even having used “new” to obtain a “service” from a different
>> bundle), why not use a factory? Actually, the previous way that you wrote
>> the util package with the publicly available Factory seems like a good
>> approach to me.
>>
>> I’m not married to it, I’m just trying to understand why… Why is “new”
>> better than a factory, if both achieve the same objective?
>>
>>
>> Cheers,
>> =David
>>
>>
>>
>>> On Sep 9, 2016, at 9:53 AM, David Bosschaert <da...@gmail.com>
>> wrote:
>>>
>>> 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 <os...@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 <da...@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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: [Converter] Change in API for obtaining a Converter
Posted by Benson Margulies <bi...@gmail.com>.
And then you need 'new' for the Factory, or a static method? Somewhere, the
chain of abstraction has to stop. If you don't have any parameters that
modify the creation, 'new' is just as good as any sort of Factory or
Builder.
On Thu, Sep 8, 2016 at 10:21 PM, David Leangen <os...@leangen.net> wrote:
>
> Hi David B.,
>
> Thank for your this explanation. Much of this makes sense, but again, just
> out of curiosity…
>
> I do understand the benefit of having this type of functionality outside
> of an OSGi environment. Perhaps the same could even be said for many other
> services, too, I’m not sure.
>
> To do that, instead of using “new” (which for me is a bit of a shock; I
> don’t recall even having used “new” to obtain a “service” from a different
> bundle), why not use a factory? Actually, the previous way that you wrote
> the util package with the publicly available Factory seems like a good
> approach to me.
>
> I’m not married to it, I’m just trying to understand why… Why is “new”
> better than a factory, if both achieve the same objective?
>
>
> Cheers,
> =David
>
>
>
> > On Sep 9, 2016, at 9:53 AM, David Bosschaert <da...@gmail.com>
> wrote:
> >
> > 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 <os...@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 <da...@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
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
>
>
Re: [Converter] Change in API for obtaining a Converter
Posted by David Leangen <os...@leangen.net>.
Hi David B.,
Thank for your this explanation. Much of this makes sense, but again, just out of curiosity…
I do understand the benefit of having this type of functionality outside of an OSGi environment. Perhaps the same could even be said for many other services, too, I’m not sure.
To do that, instead of using “new” (which for me is a bit of a shock; I don’t recall even having used “new” to obtain a “service” from a different bundle), why not use a factory? Actually, the previous way that you wrote the util package with the publicly available Factory seems like a good approach to me.
I’m not married to it, I’m just trying to understand why… Why is “new” better than a factory, if both achieve the same objective?
Cheers,
=David
> On Sep 9, 2016, at 9:53 AM, David Bosschaert <da...@gmail.com> wrote:
>
> 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 <os...@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 <da...@gmail.com>
>> wrote:
>>>
>>> Yes I understand. Thank you
>>>
>>> On Sep 8, 2016 7:10 PM, "David Bosschaert" <da...@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
>>>>>>
>>>>>
>>>>
>>
>>
Re: [Converter] Change in API for obtaining a Converter
Posted by David Bosschaert <da...@gmail.com>.
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 <os...@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 <da...@gmail.com>
> wrote:
> >
> > Yes I understand. Thank you
> >
> > On Sep 8, 2016 7:10 PM, "David Bosschaert" <da...@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
> >>>>
> >>>
> >>
>
>
Re: [Converter] Change in API for obtaining a Converter
Posted by David Leangen <os...@leangen.net>.
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 <da...@gmail.com> wrote:
>
> Yes I understand. Thank you
>
> On Sep 8, 2016 7:10 PM, "David Bosschaert" <da...@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 <da...@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
>>>>
>>>
>>
Re: [Converter] Change in API for obtaining a Converter
Posted by David Daniel <da...@gmail.com>.
Yes I understand. Thank you
On Sep 8, 2016 7:10 PM, "David Bosschaert" <da...@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 <da...@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
> > >
> >
>
Re: [Converter] Change in API for obtaining a Converter
Posted by David Bosschaert <da...@gmail.com>.
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 <da...@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
> >
>
Re: [Converter] Change in API for obtaining a Converter
Posted by David Daniel <da...@gmail.com>.
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
>