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 ha
Sorry, I meant Rule and not FunctionThrowsException
On Fri, Sep 9, 2016 at 9:47 AM, David Daniel
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 impleme
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
Some more comments inline.
On 8 September 2016 at 20:00, David Leangen 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 poin
:-)
“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 th
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 wrote:
>
> Hi David B.,
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 tha
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
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 wrote:
>
> Yes I understand. Thank you
>
> On Sep 8, 2016 7:10 PM,
Yes I understand. Thank you
On Sep 8, 2016 7:10 PM, "David Bosschaert"
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... n
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 Defe
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
converterfacto
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 ca
13 matches
Mail list logo
