[
https://issues.apache.org/jira/browse/SLING-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15465168#comment-15465168
]
Stefan Seifert commented on SLING-6025:
---------------------------------------
i first thought about this as well, but do not wanted to mix up with the OSGi
metatype to avoid confusion whether it's a context-aware or system-level
configuration. but it's a good idea to discuss it here if its maybe the better
chose nevertheless.
benefits using Metatype:
* reusing the existing osgi metatype anotations {{@ObjectClassDefinition}} and
{{@AttributeDefinition}}
* annotation classes are parsed at compile time, metadata is available at
runtime by metatype service
* we do not need classpath scanning mechanisms at runtime because the classes
are detected on compile time and metadata files generated for each
* the same annotation class could be used for both context-aware configuration
and osgi declarative services
drawbacks using Metatype:
* we mix two different configuration approaches working technically completely
different - but sharing a common configName/metatype id namespace. this may be
especially problematic when a custom (short) configName is used instead of the
full class name.
* both annotations currently provide much more properties that we are currently
plan to support - e.g. @ObjectClassDefinition,
AttributeDefinition.type/cardinality/min/max/options etc. - we may just ignore
them, or add a usefull implementation for them
* we have no possibility to pass in additional custom properties - this is
needed esp. on attribute level to provide metadata for a graphical GUI editor -
e.g. to configure a "pathbrowser" widget for a string parameter instead of a
simple text field. we may create a custom annotation only for this usecase, but
it will not be parsed and transported by the metatype functionality.
* people may get confused with this different configuration approaches sharing
some functionality but not all
> 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)
