ok, others agree as well it is a good idea to enhance the conversion support in ValueMapDecorator.
now i'm wondering how we can share the conversion logic for the JCR data types between Sling API and jcr.resource. one solution would be create a new package in sling API, move the converters there and perhaps refactor the API a bit to support a single point of entry which is able to convert an "Object" to "anything" (singleton or array of commonly used data types like primitives, date, calendar, bigdecimal etc.). but this feels very similar to the OSGi object conversion service (RFP-169, [1]), which also has a first implementation in felix [2]. this has much more features. but I think we definitely do not want a dependency of the Sling API to this conversion service, especially as the spec is not finalized and nor release exists yet. so, what about defining only an "conversion interface" in the Sling API, limit it per javadocs to support only a fixes list of types and conversions, and start with providing an own implementation in a new bundle based on what is in jcr.resource today. we may replace it later with an impl based on OSGi conversion service. stefan [1] https://github.com/osgi/design/raw/master/rfps/rfp-0169-Object-Conversion.pdf [2] https://github.com/apache/felix/tree/trunk/converter >-----Original Message----- >From: Stefan Seifert [mailto:sseif...@pro-vision.de] >Sent: Monday, December 19, 2016 12:41 PM >To: dev@sling.apache.org >Subject: [api] type conversion in ValueMapDecorator > >SLING-6416 revealed a problem in the type conversion logic of the >ValueMapDecorator [1] of the Sling API not supporting BigDecimal >conversions. > >as the TODO indicates (present there for nearly 8 years) the current >conversion logic is not very smart (and not very efficient), and supports >less conversions than the JCR value map implementation. in jcr.resource a >set of internal converters takes care of the conversion (NumberConverter, >CalendarConverter, BooleanConverter etc. [2]). > >the contract of the ValueMap interface does not define which conversions >should be supported exactly, but one might expect that a map enhanced with >ValueMapDecorator should behave at least for the conversion rules the same >way as the JCR value map. > >in this case we should move these converter implementation to the sling API >and use them in both ValueMapDecorator and jcr.resource implementation. > >WDYT? > >stefan > >[1] >https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/ap >ache/sling/api/wrappers/ValueMapDecorator.java#L64 >[2] >https://github.com/apache/sling/tree/trunk/bundles/jcr/resource/src/main/ja >va/org/apache/sling/jcr/resource/internal/helper > >
