Re: [Converter] Change in API for obtaining a Converter

[David Leangen]

:-)

“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  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  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 
>> 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  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 
 wrote:
> 
> 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... 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 

Re: [Converter] Change in API for obtaining a Converter

[Benson Margulies]

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.,
>
> 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 
> 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  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 
> >> wrote:
> >>>
> >>> 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... 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 

Re: [Converter] Change in API for obtaining a Converter

[David Leangen]

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  
> 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  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 
>> wrote:
>>> 
>>> 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... 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 

Re: [Converter] Change in API for obtaining a Converter

[David Bosschaert]

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  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 
> wrote:
> >
> > 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... 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  >
> >> 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 

Re: [Converter] Change in API for obtaining a Converter

[David Leangen]

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, "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... 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 
>> wrote:
>> 
>>> I am guessing the stuff in the org.osgi.service namespace is going into a
>>> separate bundle similar to how the other services were taken out of
>>> compendium.  Right now the StandardConverter in source control news up an
>>> apache impl converter object.  Is that code going to change to get a
>>> converterfactory from the service registry and get a converter instance
>>> from there or something like that.  The reason I am asking is that right
>>> now I have different bundles that add rules to the adapter for the
>> objects
>>> that they manage.  It happens one time on activate.  Should I be changing
>>> how I do things for instance, should my "Search" service have a function
>>> that gets a converter with the rules added and inside the get converter
>>> function it news up a standard converter and then adds the rules or
>> should
>>> I be adding rules to some global service or adapter that
>> StandardConverter
>>> will eventually get an object from.
>>> 
>>> Thanks for any help,
>>>  David Daniel
>>> 
>>> On Thu, Sep 8, 2016 at 9:30 AM, David Bosschaert <
>>> david.bosscha...@gmail.com
 wrote:
>>> 
 Hi all,
 
 The Converter API was recently discussed in the OSGi Expert Groups and
 based on the feedback the API has been refactored a bit.
 One change is how the converter is obtained in a standard way.
>> Previously
 this was done by calling ConverterFactory.standardConverter() but this
>>> is
 now done by calling 'new StandardConverter()'.
 The converter can be used inside an OSGi framework but also outside of
>>> OSGi
 in the same way. This follows a pattern used by the OSGi Promises as
>>> well.
 The Codecs will remain an OSGi service (also obtainable via
 ServiceLoader.load()) but they are renamed to 'Serializer'.
 I've made these changes to the Felix Converter codebase.
 
 This is a component that is still very much under development until the
 OSGi R7 specs are released so changes like this can happen. For those
>> who
 already use the convert it should not be too hard to update their code
>> -
 hopefully :)
 
 Cheers,
 
 David
 
>>> 
>> 

Re: [Converter] Change in API for obtaining a Converter

[David Daniel]

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... 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 
> wrote:
>
> > I am guessing the stuff in the org.osgi.service namespace is going into a
> > separate bundle similar to how the other services were taken out of
> > compendium.  Right now the StandardConverter in source control news up an
> > apache impl converter object.  Is that code going to change to get a
> > converterfactory from the service registry and get a converter instance
> > from there or something like that.  The reason I am asking is that right
> > now I have different bundles that add rules to the adapter for the
> objects
> > that they manage.  It happens one time on activate.  Should I be changing
> > how I do things for instance, should my "Search" service have a function
> > that gets a converter with the rules added and inside the get converter
> > function it news up a standard converter and then adds the rules or
> should
> > I be adding rules to some global service or adapter that
> StandardConverter
> > will eventually get an object from.
> >
> > Thanks for any help,
> >   David Daniel
> >
> > On Thu, Sep 8, 2016 at 9:30 AM, David Bosschaert <
> > david.bosscha...@gmail.com
> > > wrote:
> >
> > > Hi all,
> > >
> > > The Converter API was recently discussed in the OSGi Expert Groups and
> > > based on the feedback the API has been refactored a bit.
> > > One change is how the converter is obtained in a standard way.
> Previously
> > > this was done by calling ConverterFactory.standardConverter() but this
> > is
> > > now done by calling 'new StandardConverter()'.
> > > The converter can be used inside an OSGi framework but also outside of
> > OSGi
> > > in the same way. This follows a pattern used by the OSGi Promises as
> > well.
> > > The Codecs will remain an OSGi service (also obtainable via
> > > ServiceLoader.load()) but they are renamed to 'Serializer'.
> > > I've made these changes to the Felix Converter codebase.
> > >
> > > This is a component that is still very much under development until the
> > > OSGi R7 specs are released so changes like this can happen. For those
> who
> > > already use the convert it should not be too hard to update their code
> -
> > > hopefully :)
> > >
> > > Cheers,
> > >
> > > David
> > >
> >
>

[jira] [Assigned] (FELIX-5341) Exception thrown when field in Map missing from DTO

[David Bosschaert (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Bosschaert reassigned FELIX-5341:
---

Assignee: David Bosschaert

> Exception thrown when field in Map missing from DTO
> ---
>
> Key: FELIX-5341
> URL: https://issues.apache.org/jira/browse/FELIX-5341
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Reporter: David Leangen
>Assignee: David Bosschaert
>
> I believe that this is not the correct behaviour, so please correct me if I 
> am mistaken.
> If a Map (or Map representation of some object) contains a field, when 
> converting to a DTO that does *not* contain that field, instead of just 
> ignoring the field, an Exception is thrown, and the conversion fails.
> The related code is 
> [here|https://github.com/dleangen/felix/blob/trunk/converter/converter/src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java#L242].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [Converter] Change in API for obtaining a Converter

[David Bosschaert]

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 
wrote:

> I am guessing the stuff in the org.osgi.service namespace is going into a
> separate bundle similar to how the other services were taken out of
> compendium.  Right now the StandardConverter in source control news up an
> apache impl converter object.  Is that code going to change to get a
> converterfactory from the service registry and get a converter instance
> from there or something like that.  The reason I am asking is that right
> now I have different bundles that add rules to the adapter for the objects
> that they manage.  It happens one time on activate.  Should I be changing
> how I do things for instance, should my "Search" service have a function
> that gets a converter with the rules added and inside the get converter
> function it news up a standard converter and then adds the rules or should
> I be adding rules to some global service or adapter that StandardConverter
> will eventually get an object from.
>
> Thanks for any help,
>   David Daniel
>
> On Thu, Sep 8, 2016 at 9:30 AM, David Bosschaert <
> david.bosscha...@gmail.com
> > wrote:
>
> > Hi all,
> >
> > The Converter API was recently discussed in the OSGi Expert Groups and
> > based on the feedback the API has been refactored a bit.
> > One change is how the converter is obtained in a standard way. Previously
> > this was done by calling ConverterFactory.standardConverter() but this
> is
> > now done by calling 'new StandardConverter()'.
> > The converter can be used inside an OSGi framework but also outside of
> OSGi
> > in the same way. This follows a pattern used by the OSGi Promises as
> well.
> > The Codecs will remain an OSGi service (also obtainable via
> > ServiceLoader.load()) but they are renamed to 'Serializer'.
> > I've made these changes to the Felix Converter codebase.
> >
> > This is a component that is still very much under development until the
> > OSGi R7 specs are released so changes like this can happen. For those who
> > already use the convert it should not be too hard to update their code -
> > hopefully :)
> >
> > Cheers,
> >
> > David
> >
>

[jira] [Resolved] (FELIX-5238) ConfigurationDependency should provide the setRequired() method

[Pierre De Rop (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre De Rop resolved FELIX-5238.
--
Resolution: Fixed

I think this issue is now resolved.

> ConfigurationDependency should provide the setRequired() method
> ---
>
> Key: FELIX-5238
> URL: https://issues.apache.org/jira/browse/FELIX-5238
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Affects Versions: dependencymanager-4.3.0
>Reporter: Guillaume Nodet
>Assignee: Pierre De Rop
> Attachments: FELIX-5238.patch, 
> OptionalConfigurationDependencyTest.java
>
>
> Even though the default required for configuration is {{true}}, there's no 
> reason why it could not be {{false}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5238) ConfigurationDependency should provide the setRequired() method

[Pierre De Rop (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15475220#comment-15475220
 ] 

Pierre De Rop commented on FELIX-5238:
--

Added support for optional configuration dependencies in dm-lambda library (in 
revision 1759920).

test case: 
org.apache.felix.dependencymanager.lambda.itest/src/org/apache/felix/dm/lambda/itest/OptionalConfigurationTest.java


> ConfigurationDependency should provide the setRequired() method
> ---
>
> Key: FELIX-5238
> URL: https://issues.apache.org/jira/browse/FELIX-5238
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Affects Versions: dependencymanager-4.3.0
>Reporter: Guillaume Nodet
>Assignee: Pierre De Rop
> Attachments: FELIX-5238.patch, 
> OptionalConfigurationDependencyTest.java
>
>
> Even though the default required for configuration is {{true}}, there's no 
> reason why it could not be {{false}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-2100) Initial Config Loader

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved FELIX-2100.
-
Resolution: Implemented

This is handled by the new Configurator

> Initial Config Loader
> -
>
> Key: FELIX-2100
> URL: https://issues.apache.org/jira/browse/FELIX-2100
> Project: Felix
>  Issue Type: New Feature
>  Components: Bundle Repository (OBR), Configuration Admin
>Reporter: Róbert Csákány
> Attachments: configloader.zip
>
>
> I've a request to be able to make customer specific configuration bundles - 
> bundles that includes Configurations for other bundles. If a bundle is 
> deployed, extracts the configuration files and register it with configadmin. 
> If bundle is removed, removes configurations. If you have ideas, please share 
> it! (I'm new in this Felix world, I've used it only with Sling as a user)
> I will make a short proporsal and a whiteboard implementation.
> The name of impmelemtation is configloader
> The configloader service will implement the SynchronousBundleListener, and 
> registering itself in activation and unregistering in deactivation.
> When a new bundle is registering, checking the Bundle-InitialConfigurations 
> in META-INF/MANIFEST.MF file. If the entry is presented, checking the given 
> folders for *.xml files describes the configurations entry. (To handle the 
> Factory services also).
> Is it correct?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-5038) Configuration properties are not synchronized with config files when adding Metatype information

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated FELIX-5038:

Component/s: (was: Configuration Admin)
 File Install

> Configuration properties are not synchronized with config files when adding 
> Metatype information
> 
>
> Key: FELIX-5038
> URL: https://issues.apache.org/jira/browse/FELIX-5038
> Project: Felix
>  Issue Type: Bug
>  Components: File Install
>Reporter: Gregor Zurowski
>Priority: Minor
>
> In a Karaf/Blueprint setup, I noticed an issue related to Config Admin and 
> Felix File Install where configuration properties are not synchronized with 
> the corresponding configuration file once Metatype information is added to 
> the bundle.
> In a simple test bundle, the configuration properties are implemented using 
> property placeholders in Blueprint as follows:
> {code:title=blueprint/blueprint.xml}
> [...] 
>  persistent-id="test.config" update-strategy="reload"> 
>
>  
>
>  
> [...] 
> {code}
> The corresponding configuration file in $KARAF_HOME/etc looks as follows:
> {code:title=etc/test.config.cfg}
> [...] 
> test.property.1 = Test Value 1 
> [...] 
> {code}
> When adding the following Metatype information, the synchronization mechanism 
> stops working, i.e. changes made in OSGi config admin using  webconsole are 
> not written back to the configuration file:
> {code:title=metatype/metatype.xml}
> [...]
>  type="String" default="Default value 1" description="This is test 
> property 1" />
> [...]
> {code}
> The only way to fix synchronization is to add the following attribute 
> definition to Metatype:
> {code:title=metatype/metatype.xml}
> [...]
>  required="true" type="String" default="" description="Don't 
> modify this property!" />
> [...]
> {code}
> This has been also discussed on the Karaf users mailing list, see: 
> http://karaf.922171.n3.nabble.com/Blueprint-Property-Placeholders-with-Metatype-Information-td4042619.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-4511) Read in and Set configuration for bundles from a file

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler updated FELIX-4511:

Component/s: (was: Configuration Admin)
 Web Console

> Read in and Set configuration for bundles from a file
> -
>
> Key: FELIX-4511
> URL: https://issues.apache.org/jira/browse/FELIX-4511
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Affects Versions: configadmin-1.8.2
> Environment: Should work on all systems that Felix can run on. 
>Reporter: Matthew Sadowski
>Priority: Minor
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> Program the ability to set the values of the properties for bundles based on 
> a file.
> Currently there exists the the ability to output the configuration of all the 
> bundles loaded onto the Felix system to a webpage in the configuration status 
> page. There also exists the ability to download a hard copy of the file that 
> was output. This feature would give the ability to upload the downloaded 
> configuration file onto another instance of Felix. This would help replicate 
> system configuration and load balance instances of Felix without worrying 
> about human error in configuration copying.
> The updates could be  : 
> Ability to download bundle configuraiton file in JSON format.
> {
> "bunldes" : [
> {
> "bundleName" : "bname", 
> "propertyName1" : "propertyValue",
> "propertyName2" : "propertyValue"
> }
> ]
> }
> Ability to upload JSON formatted bundle configuration file to easily 
> configuration 1 or more named bundles.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5292) 5.4 Capabilities

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474496#comment-15474496
 ] 

Carsten Ziegeler commented on FELIX-5292:
-

Implemented this in the sandbox branch

> 5.4 Capabilities
> 
>
> Key: FELIX-5292
> URL: https://issues.apache.org/jira/browse/FELIX-5292
> Project: Felix
>  Issue Type: Sub-task
>  Components: Configuration Admin
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: configadmin-1.9.0
>
>
> Add osgi.implementation and osgi.service capability



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5291) 5.3 Improving Configuration Updates

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474494#comment-15474494
 ] 

Carsten Ziegeler commented on FELIX-5291:
-

Implemented this in the sandbox branch

> 5.3 Improving Configuration Updates
> ---
>
> Key: FELIX-5291
> URL: https://issues.apache.org/jira/browse/FELIX-5291
> Project: Felix
>  Issue Type: Sub-task
>  Components: Configuration Admin
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: configadmin-1.9.0
>
>
> A new method is added to the configuration object which only informs 
> listeners etc. if the configuration properties are different



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5289) 5.1 PID Handling of Factory Configurations

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474498#comment-15474498
 ] 

Carsten Ziegeler commented on FELIX-5289:
-

Implemented this in the sandbox branch

> 5.1 PID Handling of Factory Configurations
> --
>
> Key: FELIX-5289
> URL: https://issues.apache.org/jira/browse/FELIX-5289
> Project: Felix
>  Issue Type: Sub-task
>  Components: Configuration Admin
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: configadmin-1.9.0
>
>
> There are two new methods defined in RFC 227 for getting factory 
> configurations (getFactoryConfiguration)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5293) 5.5 Improved ConfigurationPlugin Support

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474499#comment-15474499
 ] 

Carsten Ziegeler commented on FELIX-5293:
-

Implemented this in the sandbox branch

> 5.5 Improved ConfigurationPlugin Support
> 
>
> Key: FELIX-5293
> URL: https://issues.apache.org/jira/browse/FELIX-5293
> Project: Felix
>  Issue Type: Sub-task
>  Components: Configuration Admin
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: configadmin-1.9.0
>
>
> A new method is added to the Configuration object to allow to call 
> configuration plugins



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5290) 5.2 Locking Configuration Records

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474493#comment-15474493
 ] 

Carsten Ziegeler commented on FELIX-5290:
-

Implemented locking in the sandbox branch

> 5.2 Locking Configuration Records
> -
>
> Key: FELIX-5290
> URL: https://issues.apache.org/jira/browse/FELIX-5290
> Project: Felix
>  Issue Type: Sub-task
>  Components: Configuration Admin
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: configadmin-1.9.0
>
>
> A new method for locking configurations is added to the Configuration object



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [Converter] Change in API for obtaining a Converter

[David Daniel]

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  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
>

[Converter] Change in API for obtaining a Converter

[David Bosschaert]

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

[jira] [Commented] (FELIX-5238) ConfigurationDependency should provide the setRequired() method

[Pierre De Rop (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15473540#comment-15473540
 ] 

Pierre De Rop commented on FELIX-5238:
--

Added in revision 1759776 a "setRequired(boolean)" method in 
@ConfigurationDependency annotation.
Added in revision 1759777 the two following test cases for 
@ConfigurationDependency annotation:

org.apache.felix.dependencymanager.runtime.itest/src/org/apache/felix/dm/runtime/itest/components/OptionalConfiguration.java
org.apache.felix.dependencymanager.runtime.itest/src/org/apache/felix/dm/runtime/itest/tests/OptionalConfigurationTest.java



> ConfigurationDependency should provide the setRequired() method
> ---
>
> Key: FELIX-5238
> URL: https://issues.apache.org/jira/browse/FELIX-5238
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Affects Versions: dependencymanager-4.3.0
>Reporter: Guillaume Nodet
>Assignee: Pierre De Rop
> Attachments: FELIX-5238.patch, 
> OptionalConfigurationDependencyTest.java
>
>
> Even though the default required for configuration is {{true}}, there's no 
> reason why it could not be {{false}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-5332) Serializer

[David Leangen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen updated FELIX-5332:
-
Attachment: patch.diff

> Serializer
> --
>
> Key: FELIX-5332
> URL: https://issues.apache.org/jira/browse/FELIX-5332
> Project: Felix
>  Issue Type: New Feature
>  Components: Converter
>Reporter: David Leangen
> Attachments: diff-serializer.txt, patch.diff
>
>
> Test case and a bit of code to show how a Serializer could work.
> To work as a Serializer, the type information needs to be embedded into the 
> output.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5332) Serializer

[David Leangen (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15473494#comment-15473494
 ] 

David Leangen commented on FELIX-5332:
--

Ok, [~bosschaert], I have simplified and integrated into the code base 
according to my understanding of your suggestions. Please take a look.

There are still (at least) two things missing:
 * Better client integration (will get back to this later)
 * Handing of Collections (will try to do this very soon)

I have attached the patch file. Hope this works, Instead of working via svn, I 
am now using git, so I created the patch from there. Feel free to go directly 
to my github clone if that's easier. :-)

Look forward to your comments.

> Serializer
> --
>
> Key: FELIX-5332
> URL: https://issues.apache.org/jira/browse/FELIX-5332
> Project: Felix
>  Issue Type: New Feature
>  Components: Converter
>Reporter: David Leangen
> Attachments: diff-serializer.txt
>
>
> Test case and a bit of code to show how a Serializer could work.
> To work as a Serializer, the type information needs to be embedded into the 
> output.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-5341) Exception thrown when field in Map missing from DTO

[David Leangen (JIRA)]

David Leangen created FELIX-5341:


 Summary: Exception thrown when field in Map missing from DTO
 Key: FELIX-5341
 URL: https://issues.apache.org/jira/browse/FELIX-5341
 Project: Felix
  Issue Type: Bug
  Components: Converter
Reporter: David Leangen


I believe that this is not the correct behaviour, so please correct me if I am 
mistaken.

If a Map (or Map representation of some object) contains a field, when 
converting to a DTO that does *not* contain that field, instead of just 
ignoring the field, an Exception is thrown, and the conversion fails.

The related code is 
[here|https://github.com/dleangen/felix/blob/trunk/converter/converter/src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java#L242].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5238) ConfigurationDependency should provide the setRequired() method

[Pierre De Rop (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15473327#comment-15473327
 ] 

Pierre De Rop commented on FELIX-5238:
--

Commited the improvement in revision 1759769.

test case: 
org.apache.felix.dependencymanager.itest/src/org/apache/felix/dm/itest/api/OptionalConfigurationDependencyTest.java

Tomorrow, I will apply the same to the dm-lambda library, as well as to the dm 
annotations.

> ConfigurationDependency should provide the setRequired() method
> ---
>
> Key: FELIX-5238
> URL: https://issues.apache.org/jira/browse/FELIX-5238
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Affects Versions: dependencymanager-4.3.0
>Reporter: Guillaume Nodet
>Assignee: Pierre De Rop
> Attachments: FELIX-5238.patch, 
> OptionalConfigurationDependencyTest.java
>
>
> Even though the default required for configuration is {{true}}, there's no 
> reason why it could not be {{false}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Commented] (FELIX-5238) ConfigurationDependency should provide the setRequired() method

[Pierre De Rop]

ok, I will commit all this tomorrow I think.
thank you.



On Thu, Sep 8, 2016 at 10:38 AM, J.W. Janssen (JIRA) 
wrote:

>
> [ https://issues.apache.org/jira/browse/FELIX-5238?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=15473219#comment-15473219 ]
>
> J.W. Janssen commented on FELIX-5238:
> -
>
> That objection is kind of moot: you can think of lots of use cases where a
> default configuration can be defined that allows your component to function
> properly as-is out of the box. Now, I've to resort to use the "old style"
> ManagedService implementation with all of its boilerplate stuff to get this
> configuration into my component.
>
> Please go ahead and commit your proposed changes. This discussion has been
> open long enough for everybody to react and object...
>
> > ConfigurationDependency should provide the setRequired() method
> > ---
> >
> > Key: FELIX-5238
> > URL: https://issues.apache.org/jira/browse/FELIX-5238
> > Project: Felix
> >  Issue Type: Improvement
> >  Components: Dependency Manager
> >Affects Versions: dependencymanager-4.3.0
> >Reporter: Guillaume Nodet
> >Assignee: Pierre De Rop
> > Attachments: FELIX-5238.patch, OptionalConfigurationDependenc
> yTest.java
> >
> >
> > Even though the default required for configuration is {{true}}, there's
> no reason why it could not be {{false}}.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

[jira] [Commented] (FELIX-5238) ConfigurationDependency should provide the setRequired() method

[J.W. Janssen (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15473219#comment-15473219
 ] 

J.W. Janssen commented on FELIX-5238:
-

That objection is kind of moot: you can think of lots of use cases where a 
default configuration can be defined that allows your component to function 
properly as-is out of the box. Now, I've to resort to use the "old style" 
ManagedService implementation with all of its boilerplate stuff to get this 
configuration into my component. 

Please go ahead and commit your proposed changes. This discussion has been open 
long enough for everybody to react and object...

> ConfigurationDependency should provide the setRequired() method
> ---
>
> Key: FELIX-5238
> URL: https://issues.apache.org/jira/browse/FELIX-5238
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Affects Versions: dependencymanager-4.3.0
>Reporter: Guillaume Nodet
>Assignee: Pierre De Rop
> Attachments: FELIX-5238.patch, 
> OptionalConfigurationDependencyTest.java
>
>
> Even though the default required for configuration is {{true}}, there's no 
> reason why it could not be {{false}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5338) Clarification of Converter.getAdapter()

[David Leangen (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15473095#comment-15473095
 ] 

David Leangen commented on FELIX-5338:
--

Cool, thanks! :-)

> Clarification of Converter.getAdapter()
> ---
>
> Key: FELIX-5338
> URL: https://issues.apache.org/jira/browse/FELIX-5338
> Project: Felix
>  Issue Type: Improvement
>  Components: Converter
>Reporter: David Leangen
>Assignee: David Bosschaert
>
> Hi!
> The intent of Converter.getAdapter() is not quite clear to me.
> {code}
>   /**
>* Obtain an adapter to this converter. The adapter behaves just like 
> the
>* converter except for the exception rules registered with is. For more
>* details see the {@link Adapter} interface.
>* 
>* @return An adapter to this converter.
>*/
>   Adapter getAdapter();
> {code}
> Is this supposed to return an *existing* Adapter? Or rather, should it return 
> a *new* Adapter.
> My guess is the latter, and the implementation code aligns with my 
> expectation. However, it is not clear from the documentation or the API.
> Suggestion: the method should be renamed to "newAdapter()".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (FELIX-5338) Clarification of Converter.getAdapter()

[David Leangen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed FELIX-5338.


> Clarification of Converter.getAdapter()
> ---
>
> Key: FELIX-5338
> URL: https://issues.apache.org/jira/browse/FELIX-5338
> Project: Felix
>  Issue Type: Improvement
>  Components: Converter
>Reporter: David Leangen
>Assignee: David Bosschaert
>
> Hi!
> The intent of Converter.getAdapter() is not quite clear to me.
> {code}
>   /**
>* Obtain an adapter to this converter. The adapter behaves just like 
> the
>* converter except for the exception rules registered with is. For more
>* details see the {@link Adapter} interface.
>* 
>* @return An adapter to this converter.
>*/
>   Adapter getAdapter();
> {code}
> Is this supposed to return an *existing* Adapter? Or rather, should it return 
> a *new* Adapter.
> My guess is the latter, and the implementation code aligns with my 
> expectation. However, it is not clear from the documentation or the API.
> Suggestion: the method should be renamed to "newAdapter()".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (FELIX-5335) Addition of copy() method to API

[David Leangen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Leangen closed FELIX-5335.

Resolution: Won't Fix

> Addition of copy() method to API
> 
>
> Key: FELIX-5335
> URL: https://issues.apache.org/jira/browse/FELIX-5335
> Project: Felix
>  Issue Type: New Feature
>  Components: Converter
>Reporter: David Leangen
>
> Just to keep a record of this somewhere... here is the request I posted to 
> the mail list.
> 
> bq. Is there a simple way to transform a DTO into an immutable value object?
> To put my question into context: on the bndtools list, I asked this question, 
> and got this response Peter K.:
> bq.Not in enRoute and not in the new spec that was inspired by this service. 
> In general you pass copies so they can do whatever they like with them.
> Fine. But I am not seeing a simple way of creating such copy. Is there a 
> “clone” method of some sort, or do I just convert an object to another object 
> of its own type? Like this:
>  MyDTO copy = cnv.convert( dto ).to( MyDTO.class );
> If making copies is indeed how this service is intended to be used, it would 
> be nice to have a more explicit method for this, maybe:
>  MyDTO copy = cnv.copy( dto );



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-5335) Addition of copy() method to API

[David Leangen (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15473093#comment-15473093
 ] 

David Leangen commented on FELIX-5335:
--

Those are all very good arguments. I suppose that it comes down to precision 
vs. convenience, because IIUC either way, the behaviour would have to be 
documented in the API doc.

Since it is only a very minor convenience anyway, and the target audience is 
technical people, I have no problem with choosing precision over convenience. 
:-)

> Addition of copy() method to API
> 
>
> Key: FELIX-5335
> URL: https://issues.apache.org/jira/browse/FELIX-5335
> Project: Felix
>  Issue Type: New Feature
>  Components: Converter
>Reporter: David Leangen
>
> Just to keep a record of this somewhere... here is the request I posted to 
> the mail list.
> 
> bq. Is there a simple way to transform a DTO into an immutable value object?
> To put my question into context: on the bndtools list, I asked this question, 
> and got this response Peter K.:
> bq.Not in enRoute and not in the new spec that was inspired by this service. 
> In general you pass copies so they can do whatever they like with them.
> Fine. But I am not seeing a simple way of creating such copy. Is there a 
> “clone” method of some sort, or do I just convert an object to another object 
> of its own type? Like this:
>  MyDTO copy = cnv.convert( dto ).to( MyDTO.class );
> If making copies is indeed how this service is intended to be used, it would 
> be nice to have a more explicit method for this, maybe:
>  MyDTO copy = cnv.copy( dto );



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)