You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall (JIRA)" <ji...@apache.org> on 2013/03/06 01:02:14 UTC
[jira] [Comment Edited] (FELIX-3907) NullPointerException in
BundleWiringImpl when m_disposed is true.
[ 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