[
https://issues.apache.org/jira/browse/SLING-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15469114#comment-15469114
]
Carsten Ziegeler commented on SLING-6025:
-----------------------------------------
Ok, so the resource/performance problems could be solved, but what I don't like
is that once you configure the package in the header, everything in the package
is scanned. You have no way of filtering out classes. This might sound like a
wired use case, but imagine you have three classes with annotations in that
package but you want only metadata for two of them - and of course you want all
three classes in that bundle. Then there is no way.
The tooling approach with explicit descriptors give you full power about what
is used at runtime, there is no magic. Sure, it puts the burden on the build
environment. The contrast is doing a full scan at runtime, which clearly puts
the burden at runtime, with no way to opt out. The header with package names is
in the middle of these two extremes, but as imho the disadvantage that you
still need tooling at build time (to generate the header), but you don't have
that fine control.
For the tooling, I guess if we do a bnd plugin that shouldn't too complicated.
I really like the build time approach, but if I'm the only one arguing for it,
well, then I can live with the compromise of bundle headers.
> 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)
