Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
i18n 2.6.2
-
None
Description
The following exception was observed:
[sling-default-5-ResourceBundleProvider: reload all resource bundles] org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job execution of job 'org.apache.sling.i18n.impl.JcrResourceBundleProvider$1@688bc8e' with name 'ResourceBundleProvider: reload all resource bundles' : Cannot invoke "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object, java.util.Dictionary)" because "this.bundleContext" is nulljava.lang.NullPointerException: Cannot invoke "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object, java.util.Dictionary)" because "this.bundleContext" is null at org.apache.sling.i18n.impl.JcrResourceBundleProvider.registerResourceBundle(JcrResourceBundleProvider.java:532) [org.apache.sling.i18n:2.6.2]
During the deactivation of JcrResourceBundleProvider, ReloadBundle jobs that are still running can try to register new resourceBundles. This fails, if deactivate already set bundleContext to null.
Proposed solution:
- Simplify and improve the thread-safety model by encapsulating bundle service registration/deregistration and bookkeeping in the new class ResourceBundleRegistry.
- The thread-safety concerns related to registration, deregistration, bookkeeping of the resource bundles and of their associated service registrations are encapsulated in the new class.
- The object is created in the activate method and closed in the deactivated method.
- The new class receives bundleContext in the constructor, removing the need for a field in JcrResourceBundleProvider.
- The isClosed state of the new class is used as a cancel flag during deactivation to prevent new registrations, processing of new onChange events and scheduling new bundle reloading jobs during deactivation.
- Add unit tests for interleaved registration, clearing, deactivation.
Attachments
Issue Links
- links to