jbonofre opened a new issue, #754:
URL: https://github.com/apache/camel-karaf/issues/754
## Summary
`CamelAtomITest.testResultMock` (in `tests/features/camel-atom`) fails
consistently on both Java 17 and Java 21 in CI, and reproduces 100% of the time
locally. This surfaced only after PR #753 fixed the underlying OSGi
feature-resolution failures that had always blocked the `Build` check before
the `Test` job could ever run.
## Symptom
```
CamelAtomITest.testResultMock:43 mock://camel-atom-test Received message
count. Expected: <7> but was: <0>
```
`karaf.log` shows the atom consumer repeatedly failing to poll the local
test feed file:
```
Failed polling endpoint: atom://file:.../feed.atom?delay=500. Will try again
at next poll.
Caused by: [java.lang.IllegalArgumentException - Cannot find a
ResourceResolver in classpath supporting the scheme: file]
```
## Root cause (as far as traced)
- `camel-atom`'s `AtomEntryPollingConsumer` reads non-HTTP feed URIs via
`org.apache.camel.support.ResourceHelper.resolveMandatoryResourceAsInputStream(...)`.
- That resolves through `DefaultResourceLoader.getResourceResolver("file")`,
which looks up `META-INF/services/org/apache/camel/resource-resolver/file` via
`CamelContextExtension.getBootstrapFactoryFinder(String)`.
- By bytecode inspection of `camel-base` 4.22.0,
`AbstractCamelContext.createBootstrapFactoryFinder(String)` does delegate to
`PluginHelper.getFactoryFinderResolver(...).resolveBootstrapFactoryFinder(classResolver,
path)`, which should route through camel-karaf's `OsgiFactoryFinderResolver` →
`OsgiFactoryFinder` (which scans all installed bundles for the SPI file —
confirmed present in the installed `camel-base-engine` bundle).
- At runtime, however, none of the `Osgi*Resolver` DEBUG log markers in
`core/camel-core-osgi` (`OsgiFactoryFinderResolver`, `OsgiComponentResolver`,
etc.) ever fire for this test's `CamelContext`, suggesting the OSGi-aware
resolver bridge is not actually being consulted for this lookup path, even
though `AbstractCamelRouteLauncher` does construct an `OsgiDefaultCamelContext`.
- Attempts to confirm this further via Pax Exam container DEBUG logging were
inconclusive: `org.ops4j.pax.logging.DefaultServiceLog.level=DEBUG` did not
surface any DEBUG-level output at all in `karaf.log`, so the exact point where
the resolver chain diverges from the OSGi-aware path was not conclusively
pinned down with a debugger/instrumentation.
## Scope note
Per this repo's AI agent guidelines (`CLAUDE.md`), this needs investigation
to determine whether the gap is:
- a **camel-karaf** issue (the `core/camel-core-osgi` OSGi bridging not
covering the newer `ResourceResolver` SPI / the parameterized
`getBootstrapFactoryFinder(String)` path the way it covers
`Component`/`Language`/`DataFormat` resolution), or
- an **Apache Camel core** issue (the newer parameterized bootstrap factory
finder overload not honoring a custom `FactoryFinderResolver` the way the
no-arg one does).
## Reproduction
```
mvn -pl tests/features/camel-atom install -Ddump.logs.on.failure=true
```
Fails 100% of the time locally (macOS, JDK 17) and in CI (Linux, JDK 17 and
21).
## Context
Discovered while investigating why `Test (Java 17)` / `Test (Java 21)`
checks on PR #753 failed even after the `Build` check was fixed — this is the
only test failure in that run (the reactor stopped at the first failure
alphabetically, so it's not yet confirmed whether other similarly-shaped tests
would fail too once this one is resolved).
---
_Investigated by an AI coding agent (Claude Code) on behalf of JB Onofré,
while working on PR #753 (Camel 4.22.0 upgrade)._
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
