[
https://issues.apache.org/jira/browse/SLING-7194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16285655#comment-16285655
]
Julian Sedding commented on SLING-7194:
---------------------------------------
The current ordering (call it reversed if you like) is in effect for
{{AdapterFactories}} since 2012 (see SLING-2630) and has not caused any
problems since then. Even the ticket description does not mention a problem,
only an (academic - sorry ;)) expectation.
Therefore I am against this backwards incompatible change.
We have a precedent with a change of the very same nature: reversal of the
order of {{Filter}}s in Sling's servlet filter chain (see SLING-2920). This
change caused numerous subtle issues due to incorrectly ordered filters. It
took several years (!) until these issues were fully fixed in Adobe's upstream
project. And then this fix likely caused issues for some customers again,
because they had started relying on the "fixed" filter order.
Is "correcting" the order for {{AdapterFactories}} really worth repeating such
a scenario? If you think so, can you please explain where this fix brings any
business value? Thanks.
> AdapterManager sorts AdapterFactory implementations lowest ranking first
> ------------------------------------------------------------------------
>
> Key: SLING-7194
> URL: https://issues.apache.org/jira/browse/SLING-7194
> Project: Sling
> Issue Type: Bug
> Components: Extensions
> Affects Versions: Adapter 2.1.10
> Reporter: Stefan Seifert
>
> the current implementation of AdapterManager uses a
> AdapterFactoryDescriptorMap to sort the AdapterFactory implementations found.
> this is done using a TreeMap with the ServiceReference as key.
> ServiceReference implements a compareTo.
> according to its documentation the default implementation sorts with
> service-ranking lowest-first/service id highest-first:
> https://osgi.org/javadoc/r6/core/org/osgi/framework/ServiceReference.html#compareTo(java.lang.Object)
> when picking a service from multiple ones using BundleContext.getService, the
> service with hightest service ranking/lowest service id is returned.
> i would expect the same from the AdapterManager implementation - if multiple
> implementations match pick that one with highest ranking/lowest service id.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
