[iPOJO] Non-primitive typed properties and constructors

[Benjamin Debeerst <Be...@younicos.com>]

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

[Clement Escoffier <cl...@gmail.com>]

Hi,

On 29 janvier 2015 at 18:34:08, Benjamin Debeerst (benjamin.debeerst@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