[
https://issues.apache.org/jira/browse/SLING-6652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15928680#comment-15928680
]
Dirk Rudolph commented on SLING-6652:
-------------------------------------
The API change was considered like that because having n adapterTypes per
resourceType requires a mechanism to elect which one to use (similar to
ImplementationPicker). As this would be difficult to achieve which globally
registered services in the exporter use case, making the untyped API deprecated
but still keeping its functionality (aligned to the way the lookup() elects
backed by alphabetical order).
But you are right, the exporter doesn't really need them at all, not the
deprecated ones nor the newly added ones (as long as the
{{ResourceTypeBasedResourcePicker}} is in place)
> Allow multiple adapters for Models with resourceType binding
> ------------------------------------------------------------
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: Sling Models Impl 1.3.0
> Reporter: Dirk Rudolph
>
> According to
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
> the AdapterImplementations support only mapping resourceType to Adapter 1:1.
> I would like to propose extending that to support 1:n binding between
> resourceType and adapter classes.
> My use case:
> Lets assume I want to combine my models with the exporter framework to export
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but
> annotated to be exported for different selectors.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
