[
https://issues.apache.org/jira/browse/FELIX-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260106#comment-13260106
]
Jesse Glick commented on FELIX-3477:
------------------------------------
FWIW, a bit more information gleaned from the debugger.
The class on which getMethod is being called is something like this:
class SFS extends FileSystem implements LookupListener {
@Override public void resultChanged(LookupEvent ev) {...}
}
where the superclass has
class FileSystem
public void addFileChangeListener(FileChangeListener l);
public void removeFileChangeListener(FileChangeListener l);
}
and someone has attached a weak FileChangeListener to this SFS instance. (The
SFS also called addLookupListener(this) on another object.)
Now later, during bundle unloading, the weak FCL is collected, and the cleanup
thread tries to call removeFCL on the SFS, so it uses Class.getMethod to find
this method. But that delegates to Class.getDeclaredMethods0, which calls
loadClass on LookupEvent, presumably since no lookup event happened to be
delivered in the body of this test. If LookupEvent has not been preloaded (as
in the FELIX-2128 workaround), an exception is thrown.
I checked in a demo class what happens if loadClass in this case does throw
CNFE, since getDeclaredMethods0 does not rethrow it; seems that a
NoClassDefFoundError is rethrown, which is not ideal but OK (matches what
FELIX-2128 produces).
> NPE in BundleWiringImpl.searchImports
> -------------------------------------
>
> Key: FELIX-3477
> URL: https://issues.apache.org/jira/browse/FELIX-3477
> Project: Felix
> Issue Type: Bug
> Components: File Install
> Affects Versions: framework.security-1.0.0
> Environment: JDK 6u31, Ubuntu
> Reporter: Jesse Glick
>
> NetBeans unit tests in the org.netbeans.core.osgi module pass but print a lot
> of stack traces when run against Felix 4.0.2:
> Apr 23, 2012 7:06:57 PM org.openide.util.lookup.implspi.ActiveQueue$Daemon run
> WARNING: Cannot process
> org.openide.util.WeakListenerImpl$ListenerReference@1ce1bea
> java.lang.NullPointerException
> at
> org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1508)
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1427)
> at
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
> at java.lang.Class.getMethod0(Class.java:2670)
> at java.lang.Class.getMethod(Class.java:1603)
> at
> org.openide.util.WeakListenerImpl$ListenerReference.getRemoveMethod(WeakListenerImpl.java:614)
> at
> org.openide.util.WeakListenerImpl$ListenerReference.run(WeakListenerImpl.java:572)
> at
> org.openide.util.lookup.implspi.ActiveQueue$Daemon.run(ActiveQueue.java:185)
> (The ActiveQueue thread in this case is looking for listeners attached via
> weak references which have since been collected, so that the stub listener
> can be cleanly detached from the observable object. It is impossible to
> guarantee exactly when this cleanup will run.)
> Presumably BundleRevisionImpl.m_wiring is null. searchImports should I think
> just treat this as if result==null. Can offer a patch if you like.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
