[
https://issues.apache.org/jira/browse/SLING-12091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774155#comment-17774155
]
Konrad Windszus edited comment on SLING-12091 at 10/11/23 5:42 PM:
-------------------------------------------------------------------
It seems that we incorrectly assume that bind.... is called after activate...
which is not true
(https://stackoverflow.com/questions/15782740/which-one-is-called-first-activate-function-or-bind-function-in-scr-runtime).
was (Author: kwin):
According to
https://github.com/apache/sling-org-apache-sling-resourcemerger/blob/a1a9fda3d0231e0c6ee5eeda10567bb2625099b4/src/main/java/org/apache/sling/resourcemerger/impl/MergedResourcePickerWhiteboard.java#L100,
the NPE occurs because the passed {{properties}} is {{null}}. According to
https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#service.component-method.injection
the bind method may have two parameters where the one with type {{Map}} will
receive the service properties. It is unclear how that can be {{null}}. You are
not supposed to call {{bindMergedResourcePicker2}} manually but rather let
Felix SCR deal with it.
Can you debug further and also provide the full stack trace to see why the
{{properties}} argument is {{null}}?
> [RESOURCE MERGER] NullPointerException when creating new Resource Provider
> --------------------------------------------------------------------------
>
> Key: SLING-12091
> URL: https://issues.apache.org/jira/browse/SLING-12091
> Project: Sling
> Issue Type: Bug
> Affects Versions: Resource Merger 1.4.2, Resource Merger 1.4.4
> Reporter: Guillaume Douillet
> Priority: Major
>
> Hello,
> We have a custom implementation of MergedResourcePicker2, and after applying
> a patch bumping Sling Resource Merger bundle to 1.4.2 the creation of our
> ResourceProvider service was failing in MergedResourcePickerWhiteboard with
> the following exception :
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.sling.resourcemerger.impl.MergedResourcePickerWhiteboard.registerMergingResourceProvider(MergedResourcePickerWhiteboard.java:100)
> at
> org.apache.sling.resourcemerger.impl.MergedResourcePickerWhiteboard.bindMergedResourcePicker2(MergedResourcePickerWhiteboard.java:77)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) {code}
> Looking at the source of MergedResourcePickerWhiteboard, it could be related
> to bundleContext being null.
> It could happen because after applying the patch, the Sling Merge Resource
> bundle is started after the bundle containing our MergedResourcePicker2
> implementation.
> On a test instance where our bundle starts after Sling Merge Resource bundle,
> there is no such exception and our custom Resource Provider service is
> properly registered.
> As a temporary workaround we added some fake dependencies to force our
> Resource Picker service to start after Sling OOTB implementations :
> {code:java}
> reference = {
> // fake references to make sure this service starts only after Sling
> MergedResourcePickerWhiteboard is available
> @Reference(service = ResourceProvider.class,
> target = "(provider.root=/mnt/override)",
> name = "$$scr$$ResourceProvider1",
> policyOption = ReferencePolicyOption.GREEDY),
> @Reference(service = ResourceProvider.class,
> target = "(provider.root=/mnt/overlay)",
> name = "$$scr$$ResourceProvider2",
> policyOption = ReferencePolicyOption.GREEDY)}{code}
> However it's not sustainable on the long run as these OOTB implementations
> can changed or be removed in the future.
> Thanks a lot
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
