[ 
https://issues.apache.org/jira/browse/SLING-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15428425#comment-15428425
 ] 

Stefan Seifert commented on SLING-5982:
---------------------------------------

another thought: if we only support annotation classes for conversion and 
nothing of the other features of the osgi converter service we may think about 
not using it at all.
currently we are using only very few lines of code from it (basically only one 
method 
[ConvertingImpl#createProxy|https://github.com/apache/felix/blob/trunk/converter/src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java#L311]
 mentioned above).

and now we want to replace this method with a custom adapter, using nearly 
nothing of the converter at all, because we want to stick to the conversion 
magic from the jcr value map implementation (or whatever resource provider is 
used), and need the special handling for nested configurations.

> Use custom converter adaption from ValueMap to Annotation class
> ---------------------------------------------------------------
>
>                 Key: SLING-5982
>                 URL: https://issues.apache.org/jira/browse/SLING-5982
>             Project: Sling
>          Issue Type: Improvement
>          Components: Extensions
>            Reporter: Stefan Seifert
>            Assignee: Stefan Seifert
>              Labels: contextaware-config
>             Fix For: Context-Aware Configuration 1.0.0
>
>
> currently we use the out-of-the-box functionality of the OSGi converter 
> server to map a resource valuemap properties to an annotation class. this 
> works very well.
> however some things need to be improved, and we need a custom conversion 
> adapter rules for this:
> * the dynamic proxy created by the converter (see 
> [ConvertingImpl#createProxy|https://github.com/apache/felix/blob/trunk/converter/src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java#L311])
>  only knows the Map interface, not ValueMap, thus it accesses directly the 
> "raw" type from the value map. all the conversion magic that exists in the 
> JCR value map implementation is not applied. the converter has it's own 
> magic, but it will not always produce the same results as the JCR mapping 
> magic. thus we need an adaption rule from ValueMap to <any annotation class> 
> which used the valuemap get methods with the type required for the property 
> as second argument.
> * problem: the converter service currently supports explicit mappings from 
> type A to B, not mapping from type A to any type. most of the rule method 
> variants are currently not implemented in the felix converter impl. i will 
> post a question for this issues on the felix mailing list.
> once we have this custom conversion rule in place we can do further 
> improvements:
> * create our own sling-variant of "ConversionException" and make sure it is 
> thrown in all relevant cases (on conversion, on property accesS) instead of 
> the built-in one from the conversion service
> * support nested configurations and nested configuration lists - when access 
> to a subresource is detected (does currently not work, valuemap returns null) 
> adapt the subresource to valuemap and convert it.



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

Reply via email to