[
https://issues.apache.org/jira/browse/SLING-12315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elia Colombo updated SLING-12315:
---------------------------------
Description:
The following exception was observed:
{code:java}
[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]{code}
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.
was:
The following exception was observed:
{code:java}
[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]{code}
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:
* use bundleContext as cancel flag during deactivation (bundleContext=null)
* prevent new registration of resources during deactivation (necessary)
* prevent processing of new onChange events during deactivation (improvement)
* prevent scheduling of new bundle reloading jobs during deactivation
(improvement)
* execute clearCache after setting bundleContext to null, to prevent new
registrations (improvement)
BundleContext can be used as cancel flag, since conveniently it is anyway set
to null during deactivation. New registrations can be effectively avoided by
checking bundleContext==null before any registration within a synchronized
block.
> A race condition leads to failing resource-bundle registration during
> deactivation
> ----------------------------------------------------------------------------------
>
> Key: SLING-12315
> URL: https://issues.apache.org/jira/browse/SLING-12315
> Project: Sling
> Issue Type: Bug
> Components: i18n
> Reporter: Elia Colombo
> Assignee: Elia Colombo
> Priority: Major
> Fix For: i18n 2.6.4
>
>
> The following exception was observed:
> {code:java}
> [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]{code}
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
