[
https://issues.apache.org/jira/browse/SLING-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15448862#comment-15448862
]
Carsten Ziegeler commented on SLING-6016:
-----------------------------------------
[[email protected]] I'm not 100% sure what the right approach is. Before
this change we had:
- adapting the found resource to a ValueMap - which is a low level
configuration holder
- adapting the found resource to an annotation class - which is a very cool
way as it also allows to easily provide default values etc
I thought it's natural that if you know that your configuration resources can
be adapted to something useful, to use the same API. If we move this to the
ConfigurationResourceResolver we should also move adapting to a ValueMap to the
ConfigurationResourceResolver - I think the same arguments apply here.
Now, for ValueMap and annotation class we can provide default objects - for any
arbitrary class we can't - and that's where the mismatch is. While an "empty"
annotation object can still be useful as it has its default values, an empty
ValueMap is not really useful - it's as useful as "null" but makes handling it
slightly easier.
Let's look at it from another perspective: if we don't support
resource.adaptTo() and you try to get the configuration as Foo.class (which is
not an annotation) you get the above mentioned exception. Supporting
resource.adaptTo() does not change this - however, if
resource.adaptTo(Foo.class) returns something, it works.
Ok, all of these are just random thoughts on the topic :)
We already have to distinguish between ValueMap and an annotation class when
describing the API - which is already not nice. We could think about changing
this (I know I was initially in favour of merging this , but at that point I
wasn't thinking about the fact that we limit it to convert to annotation
classes, I was more thinking about the OSGi converter which can convert to
anything...ok that failed....). So we could come up with:
as(Annotation Class)
asAdaptable(Class)
asValueMap()
The downside is that we would also need three methods for the collections - but
at least we could clearly describe what happens.
Alternatively we only support converting to annotation classes - no ValueMap
but provide a method which returns the config resource instead. But that could
return null again...
Difficult
> Context-Aware Config: Support adapting configuration resources
> --------------------------------------------------------------
>
> Key: SLING-6016
> URL: https://issues.apache.org/jira/browse/SLING-6016
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: Context-Aware Configuration 1.0.0
> Reporter: Stefan Seifert
> Assignee: Stefan Seifert
> Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> carsten introduced in rev. 1758332 a new feature:
> the ConfigurationBuilder#as method should also support adapting to any other
> object for which a sling adapter manager exits, not only to configuration
> annotation classes.
> this is currently not reflected in the API, and unit tests are missing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
