Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
MIME-Version: 1.0
In-Reply-To: <62402056-5801-4923-A72E-F37F0E78F086@leangen.net>
References: <CAMit8SqiBjd410sKDMhG0_cowZNFO7r5whxHb0UZVMNA=+V7Aw@mail.gmail.com>
 <CAP+1itPv7OkPRjieNA+6CfugdGTFKsd5Th6JrteZtEnfrWbVEw@mail.gmail.com>
 <CAMit8SpJC_rS4SWwExiEWiQnqDRRnxd2DY7jWDgZeWqc40Vyyg@mail.gmail.com>
 <CAP+1itNBKZgGZD0AkWVoCxnVP4a6x+CCJ-non3MUXtDHBUNt9A@mail.gmail.com>
 <8E64C0C7-B2C9-41BC-AB35-391141CCDA99@leangen.net> <CAMit8So6e+fJQJCt-p7Ywnn3g+Ri5CYFhMAn5NUPnRA-cxQ=dg@mail.gmail.com>
 <75EE6B39-BC9F-4ABF-8498-837E7630630A@leangen.net> <CALhtWkeSLzHnTp-DhEgLoRZHcO9g5LV=gU8GjeNuT2PjwxrP1A@mail.gmail.com>
 <62402056-5801-4923-A72E-F37F0E78F086@leangen.net>
From: David Daniel <david.daniel.1979@gmail.com>
Date: Fri, 9 Sep 2016 09:47:16 -0400
Message-ID: <CAP+1itOnfF=7CU14F8BS5CW0AvK16J+Y_rRnPd3cTcrc-Y0fbA@mail.gmail.com>
Subject: Re: [Converter] Change in API for obtaining a Converter
To: dev@felix.apache.org
Content-Type: multipart/alternative; boundary=001a113d35aa6a2062053c136223
archived-at: Fri, 09 Sep 2016 13:47:24 -0000

--001a113d35aa6a2062053c136223
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <osgi@leangen.net> wrote:

>
> :-)
>
> =E2=80=9Cnew=E2=80=9D (or static) for non OSGi code, the usual service ac=
quisition 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 tak=
e
> 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,
> =3DDavid
>
>
> > On Sep 9, 2016, at 11:51 AM, Benson Margulies <bimargulies@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 <osgi@leangen.net> wrote=
:
> >
> >>
> >> Hi David B.,
> >>
> >> Thank for your this explanation. Much of this makes sense, but again,
> just
> >> out of curiosity=E2=80=A6
> >>
> >> I do understand the benefit of having this type of functionality outsi=
de
> >> of an OSGi environment. Perhaps the same could even be said for many
> other
> >> services, too, I=E2=80=99m not sure.
> >>
> >> To do that, instead of using =E2=80=9Cnew=E2=80=9D (which for me is a =
bit of a shock; I
> >> don=E2=80=99t recall even having used =E2=80=9Cnew=E2=80=9D to obtain =
a =E2=80=9Cservice=E2=80=9D 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=E2=80=99m not married to it, I=E2=80=99m just trying to understand w=
hy=E2=80=A6 Why is =E2=80=9Cnew=E2=80=9D
> >> better than a factory, if both achieve the same objective?
> >>
> >>
> >> Cheers,
> >> =3DDavid
> >>
> >>
> >>
> >>> 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 shoul=
d
> >> be a
> >>> service as well, but where services really come to shine is where you
> >>> potentially have different implementations that might provide differe=
nt
> >>> 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 man=
y
> >>> services already of which you would only typically have one at runtim=
e.
> >>>
> >>> 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 A=
PI
> >>> 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 ma=
ke
> >>> sense, especially if there is little room for variation.
> >>>
> >>> Cheers,
> >>>
> >>> David
> >>>
> >>> On 8 September 2016 at 16:42, David Leangen <osgi@leangen.net> wrote:
> >>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> Just out of pure curiosity=E2=80=A6 what is the reason for moving aw=
ay from
> >>>> services like this? This seems like quite a departure from the way
> >> things
> >>>> used to be done=E2=80=A6
> >>>>
> >>>> Cheers,
> >>>> =3DDavid
> >>>>
> >>>>
> >>>>
> >>>>> 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 instantiate=
s
> >> the
> >>>>>> Aries implementation. Other implementations can replace the Deferr=
ed
> >>>> 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 simpl=
y
> >>>> creates
> >>>>>> one by calling new StandardConverter().
> >>>>>> If you want to add customization rules, you simply obtain an Adapt=
er
> >> by
> >>>>>> calling
> >>>>>> Adapter a =3D new StandardConverter().newAdapter();
> >>>>>> Then you can add your rules to a. The Adapter a is also a Converte=
r
> -
> >> 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 o=
f
> >> your
> >>>>>> application. Its up to the application to decide how to share thes=
e
> >>>>>> 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=3Dmarkup
> >>>>>>
> >>>>>> 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 goin=
g
> >>>> into a
> >>>>>>> separate bundle similar to how the other services were taken out =
of
> >>>>>>> compendium.  Right now the StandardConverter in source control ne=
ws
> >> up
> >>>> an
> >>>>>>> apache impl converter object.  Is that code going to change to ge=
t
> a
> >>>>>>> converterfactory from the service registry and get a converter
> >> instance
> >>>>>>> from there or something like that.  The reason I am asking is tha=
t
> >>>> right
> >>>>>>> now I have different bundles that add rules to the adapter for th=
e
> >>>>>> 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 Grou=
ps
> >> 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() bu=
t
> >>>> 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 Promise=
s
> 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 thei=
r
> >> code
> >>>>>> -
> >>>>>>>> hopefully :)
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>>
> >>>>>>>> David
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>

--001a113d35aa6a2062053c136223--