[
https://issues.jboss.org/browse/JBOSGI-560?page=com.atlassian.jira.plugin...
]
Thomas Diesler commented on JBOSGI-560:
---------------------------------------
Thanks Rico
Code in question
{code}
if (LOGGER.isDebugEnabled()) {
BundleWiring wiring = getCurrentBundleRevision().getWiring();
LOGGER.tracef("Required resource wires for: %s",
wiring.getResource());
for (Wire wire : wiring.getRequiredResourceWires(null)) {
LOGGER.tracef(" %s", wire);
}
LOGGER.tracef("Provided resource wires for: %s",
wiring.getResource());
for (Wire wire : wiring.getProvidedResourceWires(null)) {
LOGGER.tracef(" %s", wire);
}
}
{code}
It should really be LOGGER.isTraceEnabled(), but that's a minor thing.
More interesting is what could possibly lead to a condition where the wiring is null. Our
test suites run with DEBUG enabled and we don't see the NPE. Adding a not null check
is probably not the right fix.
The stack trace suggests that there is some dynamic import happening. Do you have a bundle
deployment that allows me to reproduce this issue?
NullPointerException in AbstractBundleState#ensureResolved if debug
logging is enabled
--------------------------------------------------------------------------------------
Key: JBOSGI-560
URL:
https://issues.jboss.org/browse/JBOSGI-560
Project: JBoss OSGi
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Core Framework
Affects Versions: JBossOSGi 1.3.0
Reporter: Rico Neubauer
Assignee: Thomas Diesler
Labels: osgi
Occurs with JBoss 7.1.2.Final (EAP) running with jbosgi-framework 1.3.0.Final
If debug logging is enabled, method
org.jboss.osgi.framework.internal.AbstractBundleState#ensureResolved may throw a
NullPointerException in case of "wiring" being null. See stacktrace below.
Will add a pull request, doing the missing check for null.
{noformat}
Caused by: java.lang.NullPointerException
at
org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:558)
at
org.jboss.osgi.framework.internal.FallbackLoader.findInUnresolvedModules(FallbackLoader.java:230)
at
org.jboss.osgi.framework.internal.FallbackLoader.findModuleDynamically(FallbackLoader.java:156)
at
org.jboss.osgi.framework.internal.FallbackLoader.loadClassLocal(FallbackLoader.java:85)
at org.jboss.modules.Module.loadModuleClass(Module.java:535)
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
at java.lang.Class.forName0(Native Method) [rt.jar:1.6.0_31]
at java.lang.Class.forName(Class.java:247) [rt.jar:1.6.0_31]
at com.company.sth.ConnectionPool.<init>(ConnectionPool.java:131)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira