[
https://issues.apache.org/jira/browse/FELIX-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594121#comment-13594121
]
Richard S. Hall edited comment on FELIX-3907 at 3/6/13 12:01 AM:
-----------------------------------------------------------------
There is another check of m_disposed inside of getClassLoaderInternal()...
The getClassLoader() method is spec and is supposed to return null if the
wiring is disposed. That's what was causing the NPE for you. The whole point of
this patch is to introduce an internal method that will return a non-null class
loader if one exists, that's what getClassLoaderInternal() does. The only time
it still returns null is if the class loader hasn't been created yet and the
wiring is already disposed, which I believe can happen since we defer bundle
class loader creation until someone actually loads a class from a bundle.
But, in general, getClassLoaderInternal() should always return non-null and
getClassLoader() will return non-null if the wiring hasn't been disposed. The
wiring internals now use getClassLoaderInternal() so that classes can continue
to be loaded, even after disposal of the wiring. Of course, this only applies
to classes that the class loader has already loaded, any attempts to load new
bytes will result in a hopefully more meaningful exception message.
was (Author: rickhall):
There is another check of m_disposed inside of getClassLoaderInternal()...
The getClassLoader() method is spec and is supposed to return null if the
wiring is disposed. That's what was causing the NPE for you. The whole point of
this patch is to introduce an internal method that will return a non-null class
loader if one exists, that's what getClassLoaderInternal() does. The only time
it still returns null is if the class loader hasn't been created yet and the
wiring is already disposed, which I believe can happen since we defer bundle
class loader creation until someone actually loads a class from a bundle.
But, in general, getClassLoaderInternal() should always return non-null and
getClassLoader() will return non-null if the wiring hasn't been disposed. The
wiring internals now use getClassLoaderInternal() so that classes can continue
to be loaded, even after disposal of the wiring.
> 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
> Assignee: Richard S. Hall
> Fix For: framework-4.2.1
>
>
> 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
