[jira] [Updated] (SLING-5982) Use custom converter adaption from ValueMap to Annotation class

["Stefan Seifert (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Seifert updated SLING-5982:
----------------------------------
    Description: 
this is about the context-aware configuration: https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/contextaware-config

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.

  was:
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.


> 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
>
>
> this is about the context-aware configuration: https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/contextaware-config
> 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)