[ 
https://issues.apache.org/jira/browse/FELIX-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13568020#comment-13568020
 ] 

Richard S. Hall commented on FELIX-3273:
----------------------------------------

Where is the gap? Inside BundleImpl.uninstall() we do this:

        synchronized (m_cachedHeaders)
        {
            if ((m_cachedHeaders.size() > 1)
                || !m_cachedHeaders.containsKey(Locale.getDefault().toString()))
            {
                m_cachedHeaders.clear();
                Map map = 
getCurrentLocalizedHeader(Locale.getDefault().toString());
            }
        }

So, we hold the lock while clearing the cache and populating it with the 
default locale. If another thread came in, it wouldn't try to cache the default 
locale again because cache size would be 1 and it would contain the default 
locale.

Unless there was some weird possibility that the thread had a different default 
locale.
                
> Possible exception when accessing headers
> -----------------------------------------
>
>                 Key: FELIX-3273
>                 URL: https://issues.apache.org/jira/browse/FELIX-3273
>             Project: Felix
>          Issue Type: Bug
>    Affects Versions: framework-3.0.9
>            Reporter: Guillaume Nodet
>             Fix For: framework-4.2.0
>
>
> {code}
> ERROR: Bundle org.ops4j.pax.logging.pax-logging-service [3] EventDispatcher: 
> Error during dispatch. (java.util.NoSuchElementException)
> java.util.NoSuchElementException
>       at java.util.HashMap$HashIterator.nextEntry(HashMap.java:796)
>       at java.util.HashMap$ValueIterator.next(HashMap.java:822)
>       at 
> org.apache.felix.framework.BundleImpl.getCurrentLocalizedHeader(BundleImpl.java:334)
>       at org.apache.felix.framework.Felix.getBundleHeaders(Felix.java:1428)
>       at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:311)
>       at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:293)
>       at 
> org.ops4j.pax.logging.service.internal.PaxLoggerImpl.setDelegateContext(PaxLoggerImpl.java:101)
>       at 
> org.ops4j.pax.logging.service.internal.PaxLoggerImpl.debug(PaxLoggerImpl.java:131)
>       at 
> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.log(PaxLoggingServiceImpl.java:149)
>       at 
> org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.log(PaxLoggingServiceImpl.java:115)
>       at 
> org.ops4j.pax.logging.service.internal.FrameworkHandler.bundleChanged(FrameworkHandler.java:93)
>       at 
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:807)
>       at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:729)
>       at 
> org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:949)
>       at 
> org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:54)
>       at 
> org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:106)
>       at java.lang.Thread.run(Thread.java:680)
> {code}
> The problem happened on 3.0.9 but looking at the getLocalizedHeaders method, 
> nothing has changed so the bug should still be valid for 4.0.x
> I suppose the problem is in the BundleImpl#uninstall method which may clear 
> the cached headers without populating with the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to