[
https://issues.apache.org/jira/browse/SLING-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15433697#comment-15433697
]
Stefan Seifert commented on SLING-5982:
---------------------------------------
in rev. 1757438 i implemented what was desired for this ticket - use native
valuemap access and support nested configuration objects/lists.
although david quickly provided an enhanced version of the osgi converter
supporting wildcard rules ValueMap to object it did not help to solve the
nested configuration usecase where we always have to fall back to the resource
itself to inspect it's children for the nested configurations. please have a
look yourself at the ref if you see an elegant & efficient way to still make
use of the OSGi converter here.
thy only think i would really like to reuse is the "getInterfacePropertyName"
method (which is not yet fully implemented in the converter either) which
should map uncommon annotation class property names to valid names according to
the conversion rules defined in the OSGi specs.
what would be possible is to prefetch the configuration including all nested
configuration objects and prepopulate a map with nested maps and lists as
expected by the OSGi converter. but it seems to be more efficient to access the
nested configuration classes only if they are really called by the client code,
and to use as less reflection as possible in advance.
> 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)
