Guillaume Douillet created SLING-12091:
------------------------------------------
Summary: [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.4, Resource Merger 1.4.2
Reporter: Guillaume Douillet
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)
