[
https://issues.apache.org/jira/browse/FELIX-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13589880#comment-13589880
]
Richard S. Hall commented on FELIX-3907:
----------------------------------------
The degree of "closeness" just depends on the particular scenario. If a thread
has already loaded all classes it will ever need, it may never notice that a
refreshed bundle is gone. On the other hand, a thread that still has plenty of
class loads it needs to do will immediately run into "differences". There is a
complete spectrum of possibilities and we can't do anything to paper over what
happens when a thread stumbles into the situation.
Regarding what the spec requires, let's be clear, we are talking about a
situation where the bundle has been refreshed, not simply in some potential
limbo state like after an update or uninstall. The whole point of "refreshing"
is that this is when the framework let's go of everything that is currently in
a limbo state. So, in short, no it won't nor can it keep stuff around (e.g., if
you uninstall and refresh a bundle, it is gone, period).
Regarding a "good" exception, the issue really is that there are race
conditions all over the place since we don't hold any locks, plus there are
abstractions in place that hide knowledge we need. So, it is just difficult.
Granted, we've refactored a bit since I last looked into this, so perhaps it
would be possible to simply check the disposed status before trying to get any
new bytes for a given class loader and simply fail at that point with a CNFE.
That'd be about the best we could do, perhaps. And again, to be clear, this
would not eliminate weird exceptions since there is a race condition of
checking the disposed state and someone else disposing of the bundle. Perhaps
it makes them less likely, though.
> NullPointerException in BundleWiringImpl when m_disposed is true.
> -----------------------------------------------------------------
>
> Key: FELIX-3907
> URL: https://issues.apache.org/jira/browse/FELIX-3907
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-4.2.0
> Environment: Windows
> Reporter: Jad Naous
>
> NullPointerException caused by lines 1472-1474 of
> {{org.apache.felix.framework.BundleWiringImpl}} when {{this.m_disposed ==
> true}}. I don't know why {{this.m_disposed}} is true, but I'm guessing it's
> some sort of race condition. Stack trace follows:
> {noformat}
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer
> java.lang.NullPointerException: null
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1472)
> ~[felix.jar:na]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
> ~[felix.jar:na]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1923)
> ~[felix.jar:na]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> java.lang.ClassLoader.loadClass(ClassLoader.java:247) ~[na:1.6.0_37]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> java.lang.Class.getDeclaredFields0(Native Method) ~[na:1.6.0_37]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> java.lang.Class.privateGetDeclaredFields(Class.java:2291) ~[na:1.6.0_37]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> java.lang.Class.getDeclaredField(Class.java:1880) ~[na:1.6.0_37]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> com.nerati.agent.events.RuntimeRecording.getClassId(RuntimeRecording.java:156)
> ~[agent-main-0.0.5-SNAPSHOT.jar:0.0.5-SNAPSHOT]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> com.nerati.agent.events.RuntimeRecording.writeAsJson(RuntimeRecording.java:118)
> ~[agent-main-0.0.5-SNAPSHOT.jar:0.0.5-SNAPSHOT]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> com.nerati.agent.client.ControllerClient.processRequest(ControllerClient.java:160)
> ~[agent-main-0.0.5-SNAPSHOT.jar:0.0.5-SNAPSHOT]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> com.nerati.agent.client.ControllerClient.putData(ControllerClient.java:131)
> ~[agent-main-0.0.5-SNAPSHOT.jar:0.0.5-SNAPSHOT]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> com.nerati.agent.client.ControllerManager.putData(ControllerManager.java:177)
> ~[agent-main-0.0.5-SNAPSHOT.jar:0.0.5-SNAPSHOT]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> com.nerati.agent.client.ControllerSendTask.run(ControllerSendTask.java:119)
> ~[agent-main-0.0.5-SNAPSHOT.jar:0.0.5-SNAPSHOT]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> [na:1.6.0_37]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
> [na:1.6.0_37]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [na:1.6.0_37]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
> [na:1.6.0_37]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
> [na:1.6.0_37]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
> [na:1.6.0_37]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> [na:1.6.0_37]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> [na:1.6.0_37]
> ( Thread-5) [DEBUG] ntegration.NeratiDeployer at
> java.lang.Thread.run(Thread.java:662) [na:1.6.0_37]
> {noformat}
--
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
