[
https://issues.apache.org/jira/browse/FELIX-6510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17741835#comment-17741835
]
Heiko Studt commented on FELIX-6510:
------------------------------------
Currently, we are using the felix framework 7.0.3. It still installs the
Test-JAR and the bundles health check faults. However, I now could step through
using the latest felix-dev and it seems that the header was not the culprit
after all
The actual problem is that bundle.getSymbolicName() returns null which in turn
creates my NPE in regex.matches.
I apologize that I did not debug well enough a year ago.
Seemingly, the symbolic name *may* be null, if the manifest version was not 2:
(ManifestParser.java)
{code:java}
// Verify that bundle symbolic name is specified.
if (getManifestVersion().equals("2") && (m_bundleSymbolicName == null))
{
throw new BundleException(
"R4 bundle manifests must include bundle symbolic name.");
}{code}
> NPE within HealthCheck BundlesStartedCheck for bad Bundle
> ---------------------------------------------------------
>
> Key: FELIX-6510
> URL: https://issues.apache.org/jira/browse/FELIX-6510
> Project: Felix
> Issue Type: Improvement
> Components: Framework
> Reporter: Heiko Studt
> Priority: Major
>
> TL;DR: If you have configured the BundlesStartedCheck and there was any
> bundle installed without correct OSGI headers (ls is showing `null 0.0.0`),
> the BundlesStartedCheck will report some NPE and does not log anything to
> file and neither the reason nor a stack trace into the health-check frontend.
> The latter (no stack-trace) is a good thing, though.
> If you have switched on the debug-level "all", it will stop after some lines
> "Bundle [...] not matched by [...]"; the exception itself is then swallowed
> and not logged into the osgi runner log, so that one has to wonder why it has
> happened.
> In my osgi runner there was a bundle installed which was shown by "ls -l" as
> "null 0.0.0". It was created from an unit-test jar included by an error.
> According to removing that bundle is solving the problem, I assume the
> following code is the culprit.
> [https://github.com/apache/felix-dev/blob/5becb8f971f904334eb3f32e7eaa9126186a2898/healthcheck/generalchecks/src/main/java/org/apache/felix/hc/generalchecks/BundlesStartedCheck.java#L149]
> b.getHeaders().get(Constants.BUNDLE_ACTIVATIONPOLICY)
> In my point of view, we should add a null check for b.getHeader() or at least
> report the culprit bundle name of the exception.
> Should I create a Pull Request for the null check?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
