On 11/13/12 03:37, jpullmann wrote:
Hello,we encounter a weird null pointer exception in Felix 4.0.2 (underlying the Glassfish Server 3.1.2.2): [#|2012-11-09T10:18:28.024+0100|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-2;|java.lang.NullPointerException at org.apache.felix.framework.resolver.ResolverImpl.toStringBlame(ResolverImpl.java:1663) at org.apache.felix.framework.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1078) at org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:190) at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819) at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944) at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1175) at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:1153) at org.apache.felix.fileinstall.internal.DirectoryWatcher.processAllBundles(DirectoryWatcher.java:1146) at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:456) at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:263) |#] There is no further advice on bundle being loaded or nature of the error. It prevents the server to start and results in an infinite loop while glassfish tries to recover... The indicated error line: BundleCapability cap = Util.getSatisfyingCapability( blame.m_reqs.get(i + 1).getRevision(), (BundleRequirementImpl) blame.m_reqs.get(i)); l.1663 -> if (cap.getNamespace().equals(BundleRevision.PACKAGE_NAMESPACE)) references the class "BundleCapability" which has been introduced in OSGi 4.3. The felix bundle contains the OSGi core 4.3 classes as well, thus the implicit framework version is 4.3. In an installation where the OSGi 4.2. Core bundle was (accidentally) deployed along with our application bundles this error did not arise, it become apparent once this bundle was removed. Apparently the bundle resolution should not rely on a particular (new) framework version and offer a more robust and informative error handling.
Sounds like you are jumping to conclusions. The bundle resolution algorithm is part of the framework and can use anything the framework provides. This issue must be related to something else.
If you can create a set of steps to reproduce, you could open an issue and document them.
Also, you could try to replace the 4.0.2 framework with the 4.0.3 release, just in case other fixes impacted this issue.
Could you please point out which adaptations are needed to make the bundles OSGi 4.3 ready ? Could we rely on the quick workaround of co-deploying an older framework API bundle (4.2) ?
You should be able to run older bundles on newer frameworks without issue, for the most part.
-> richard
Many thanks Jaro -- View this message in context: http://apache-felix.18485.n6.nabble.com/Bundle-resolution-fails-NPE-while-processing-BundleCapability-tp5000375.html Sent from the Apache Felix - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
