[
https://issues.apache.org/jira/browse/SLING-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15466944#comment-15466944
]
Stefan Seifert commented on SLING-6025:
---------------------------------------
i played around with porting it to metatype and encountered some problems:
# biggest problem: the metatype service provides information about
objectclasses and attributes definitions, but there is not longer any
connection to the annotation class (which from an osgi perspective makes sense,
because the class is only one convenience way of defining metatypes, and not
the only way).
** for our use case this is problematic: we have a class in the config API, and
need to look up at least the configuration name if not the default (class name)
is used. we have no way of finding the attached metatype (unless its by chance
the default = class name), and no way of reading it directly from the
ObjectClass annotation because it is not available at runtime
** we also need this connection to look up the custom metadata we provide with
custom annotations in the class
** the only attribute containing a hint for the class name (if a custom
id/configname is used) is the "localization" property - but it does not seem to
be safe/correct to try to parse the class name out of a string like
{{OSGI-INF/l10n/org.apache.sling.testing.mock.osgi.metatype.SimpleConfig}}.
# if i understand the metatype service correctly the id (our configname) has
only to be unique within the bundle.
** in our use case the config name has to be unique overall the instance.
** with the metatype service it's difficult to detect and generate a warning if
someone by accidents defines a config name/objectclass id that is already in
use by another application. at least a warning should be logged.
# nested annotation classes: out of the box the maven bundle plugin/bnd does
not accept generating objectclass definitions for annotation classes containing
other annotation classes with object class defintions on it.
** when setting a special bundle header {{-metatypeannotations-options=nested}}
is it supported
** but the result is still wrong, the generated object class has attributes of
type "String"
** we could remove the support for nested annotation classes, but this would be
sad as it is useful and fits neatly into the resource hierarchy concept.
perhaps it's only an issue in bndlib
** i've not yet looked up the metatype spec if the say anything about if and
how nested metatypes should be supported
> Context-Aware Config: Provide configuration parameter metadata
> --------------------------------------------------------------
>
> Key: SLING-6025
> URL: https://issues.apache.org/jira/browse/SLING-6025
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Stefan Seifert
> Assignee: Stefan Seifert
> Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> in order to support configuration editors GUIs we need to provide metadata
> which configurations with parameter metadata are defined by the applications.
> this means:
> * list of all configurations registered (singleton, collections, nested) with
> ** their respective configuration names
> ** label (optional)
> ** description (optional)
> * list of all parameters for each configuration
> * parameter metadata:
> ** name
> ** type (only supported: String,int,long,double,boolean and arrays of them)
> ** label (optional)
> ** description (optional)
> ** default value
> ** further custom properties that may customized the configuration editor
> (e.g. widget type to use, optional)
> the applications needs a possibility to provide such configuration+parameter
> metadata. by default the annotation interface classes are used for this. they
> have to be detected on the runtime in the classpath when a new bundle is
> deployed using an osgi extender pattern (quite similar to sling models). to
> the annotation classes further annotations can be applied an class and
> property level to provide the additional metadata (label, description etc.).
> currently we can only support automatic detection of parameter metadata for
> configurations which are defined and accessed with annotation classes, not
> when the application used direct valuemap access or the low-level
> ConfigurationResourceResolver.
> by making the configuration metadata provider pluggable via an SPI we can
> ship the default configuration providing metadata detected from the deployed
> annotation classes, but leave a door open to add other sources as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
