[iPOJO] Non-primitive typed properties and constructors

2015-01-29 Thread Benjamin Debeerst
Dear iPOJO developers,

I've stumbled upon a situation with fields in components that are annotated 
with @Property but are of non-primitive and non-String type.

iPOJO has the nice feature that you still can provide default values and 
configurations as Strings and it will try to find an appropriate String 
constructor for that object. This is done in the Property class [1], starting 
from line 436 (v1.12.0). However, it will only look for the one constructor 
with a single String argument and ignore constructors with the Object argument.

For example, I often have joda-time Duration and DateTime objects as 
configurations. Those only have Object constructors which still parse Strings 
properly. Wouldn't it be a nice feature if the Property class could fall back 
and try the Object constructor when no String constructor could be found? At 
the moment I have to make them String properties and parse those into shadow 
members upon activation, which is a little cumbersome.

For my own types, I'd be able to add a String constructor, but since this is an 
external library, a cannot do that as easily.

Please let me know what you think of it and if there are any connected issues 
I'd have to think of, and I'd happily provide a patch / pull request. Should I 
open an issue on github or Jira?

Kind regards,
Benjamin


[1] 
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.felix/org.apache.felix.ipojo/1.12.0/org/apache/felix/ipojo/util/Property.java#436



Re: [iPOJO] Non-primitive typed properties and constructors

2015-01-29 Thread Clement Escoffier
Hi,

On 29 janvier 2015 at 18:34:08, Benjamin Debeerst 
(benjamin.debee...@younicos.com) wrote:

Dear iPOJO developers, 

I've stumbled upon a situation with fields in components that are annotated 
with @Property but are of non-primitive and non-String type. 

iPOJO has the nice feature that you still can provide default values and 
configurations as Strings and it will try to find an appropriate String 
constructor for that object. This is done in the Property class [1], starting 
from line 436 (v1.12.0). However, it will only look for the one constructor 
with a single String argument and ignore constructors with the Object argument. 

For example, I often have joda-time Duration and DateTime objects as 
configurations. Those only have Object constructors which still parse Strings 
properly. Wouldn't it be a nice feature if the Property class could fall back 
and try the Object constructor when no String constructor could be found? At 
the moment I have to make them String properties and parse those into shadow 
members upon activation, which is a little cumbersome. 
Yes, definitely a good idea!



For my own types, I'd be able to add a String constructor, but since this is an 
external library, a cannot do that as easily. 

Please let me know what you think of it and if there are any connected issues 
I'd have to think of, and I'd happily provide a patch / pull request. Should I 
open an issue on github or Jira? 
Please open a ticket in Jira (https://issues.apache.org/jira/browse/FELIX). If 
you can attach a patch that would be awesome (and I will be really happy to 
integrate it)

Cheers,

Clement





Kind regards, 
Benjamin 


[1] 
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.felix/org.apache.felix.ipojo/1.12.0/org/apache/felix/ipojo/util/Property.java#436