felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-3907) NullPointerException in BundleWiringImpl when m_disposed is true.
Date Wed, 06 Mar 2013 00:00:13 GMT

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

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

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

Mime
View raw message