[
https://issues.apache.org/jira/browse/FELIX-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13589833#comment-13589833
]
Jad Naous commented on FELIX-3907:
----------------------------------
Agreed, we should not hold onto to classes and we know exactly where the issue
in our application is arising from. I am not actually thinking about my
application, but just in general. Wouldn't we want the behavior to match what
happens in a non-osgi environment as much as possible? I maybe unclear here on
what OSGI requires, but shouldn't all resources related to a classloader (e.g
the jar file, which I assume throws the zip exception) and the related object
graph remain available, but just unused to instantiate new classes from other
bundles until all references to the old classloader are GC'ed and only then do
we make other related resources disappear (such as closing jars, deleting
files, etc)?
Re "good" exception, maybe there should be a check for m_disposed at the
beginning of every method call in BundleClassLoader that throws an exception
(maybe ClassLoaderNoLongerAvailableException or BundleInaccessibleException) if
m_disposed is true? Or is that what you say is difficult?
> 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
