[
https://issues.apache.org/jira/browse/SLING-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15428448#comment-15428448
]
Stefan Seifert commented on SLING-5982:
---------------------------------------
yes, this makes sense. will further check this.
on the other side: we have to keep in mind we need parameter metadata support
as well. that means supporting a management API for configuration editors which
can get a list of all configuration parameter metadata (configuration classes,
parameters, types, default values, documentation) to offer a visual
configuration editor similar to the functionality OSGi config web console, but
with support for context/paths, inheritance etc. the only source i currently
see for this metadata are the annotation classes, perhaps with further
annotations for lables/descriptions etc.
if we support to convert anything to anything in the configuration API classes,
it will become very difficult for the configuration editor to catch up and
automatically provide a generic editor GUI for edit. thus my current plan was
to stick with annotation classes only, and support only the important primitive
data types plus nested configuration classes and lists.
> 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)
