[
https://issues.apache.org/jira/browse/SLING-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582118#comment-13582118
]
Alexander Klimetschek edited comment on SLING-2477 at 2/20/13 11:40 AM:
------------------------------------------------------------------------
I suggested the service.ranking{int} syntax mostly because it's more intuitive
and because it would still use the JCR types as much as possible, instead of
going back to always using a string and loosing the usefulness of JCR types
(what the I"1000" notation implies).
It would use the "closest" JCR property type:
- byte => LONG
- short => LONG
- int => LONG
- float => DOUBLE
- char => STRING
If values exceed their interval, we can either take a best effort (first char
of a string or maximum byte/short/int/float value), ignore them or throw an
error. Don't know what's best.
For completeness, the ones hat map 1:1:
- string => STRING
- long => LONG
- double => DOUBLE
- bool => BOOLEAN
The types that are in JCR, but not in Java/OSGi configs, can be ignored. Maybe
the implementation uses the JCR property toString() mapping and sees them as
string properties (if that already happens in the current version).
If multiple properties are present (service.ranking, service.ranking{int},
service.ranking{long}) one could for example use the first valid entry. It
would be a very obvious mistake by the user/dev if he adds multiple of those
properties, so nothing that we need to do much about.
BTW, I think it's good that JCR simplifies primitive types instead of
supporting all Java primitives. I have never seen a use case for byte, short,
char or int limitations for persistence reasons.
was (Author: alexander.klimetschek):
I suggested the service.ranking{int} syntax mostly because it's more
visible and intuitive.
It would also use the "closest" JCR property type instead of always a string
(what the I"1000" notation implies):
- byte => LONG
- short => LONG
- int => LONG
- float => DOUBLE
- char => STRING
If values exceed their interval, we can either take a best effort (first char
of a string or maximum byte/short/int/float value), ignore them or throw an
error. Don't know what's best.
For completeness, the ones hat map 1:1:
- string => STRING
- long => LONG
- double => DOUBLE
- bool => BOOLEAN
The types that are in JCR, but not in OSGi config admin, can be ignored. Maybe
the implementation uses the JCR property toString() mapping and sees them as
string properties (if that already happens in the current version).
> Configuration via sling:OsgiConfig nodes does not support all types
> -------------------------------------------------------------------
>
> Key: SLING-2477
> URL: https://issues.apache.org/jira/browse/SLING-2477
> Project: Sling
> Issue Type: Bug
> Components: Installer
> Affects Versions: JCR Installer 3.1.2
> Reporter: Alexander Klimetschek
> Assignee: Ian Boston
>
> Most notably, the common "service.ranking" needs to be an Integer, while the
> jcr property mapping only allows for "Long" types at the moment. The problem
> is that JCR has a smaller set of property types than the OSGi config admin
> (JCR: String, Boolean, Long, Double, Decimal; OSGi: String, Boolean, Long,
> Integer, Float, Double, and probably more differences...).
> Similarly to properties files (which do it in the value like
> 'service.ranking=I"-10000"' with I=Integer), there must be a way to
> explicitly specify the type regardless of the JCR type. For example, encoding
> it in the property name like "service.ranking{int}".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
