[
https://issues.apache.org/jira/browse/CAMEL-24351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrik updated CAMEL-24351:
---------------------------
Description:
`@Lazy` on the mapping bean means it is created on first demand, which is
unordered against CamelContext startup. `CamelRequestHandlerMapping` registers
itself as a `PlatformHttpListener` from its constructor, and `addHttpEndpoint`
notifies only listeners existing at that moment — so if Camel starts first, the
mapping receives no callback for any endpoint and its registry stays empty.
Requests then get Spring's `BasicErrorController` 404, including the correct
path, which is what makes it confusing to diagnose.
The application looks healthy throughout: routes log `Started <route>
(rest://get:/...)`, pubsub/timer routes work, probes stay green. Two behaviours
make it fully silent — `addPlatformHttpListener` doesn't replay
`getHttpEndpoints()` to a new listener, and `addHttpEndpoint` swallows listener
exceptions at WARN. Nothing is logged for the failing requests because no route
runs.
*Regression evidence* (from the released jars' constant pools): 4.18.3 none →
eager; 4.20.0 `@DependsOn` → eager; 4.21.0 `@Lazy`. Introduced by
`264db4c12e0`, titled {*}"Fix compilation error in camel-aws-s3 (#1783)"{*},
which replaced an `ObjectProvider<CamelContext>` with direct injection plus
`@Lazy`.
*Reproduction* is environment-dependent, so I described it honestly rather than
as a recipe: roughly 1 in 3 pods came up working, fixed per pod for its
lifetime (10/30 identical requests succeeded, from 3 healthy pods of ~9). Apps
with a separate management port don't see it — the management child context
initialises its DispatcherServlet early and `beansOfTypeIncludingAncestors`
instantiates the parent's mapping before Camel starts. The deterministic check
is the bean definition's `isLazyInit()`.
PR: [https://github.com/apache/camel-spring-boot/pull/1874]
was:
`@Lazy` on the mapping bean means it is created on first demand, which is
unordered against CamelContext startup. `CamelRequestHandlerMapping` registers
itself as a `PlatformHttpListener` from its constructor, and `addHttpEndpoint`
notifies only listeners existing at that moment — so if Camel starts first, the
mapping receives no callback for any endpoint and its registry stays empty.
Requests then get Spring's `BasicErrorController` 404, including the correct
path, which is what makes it confusing to diagnose.
The application looks healthy throughout: routes log `Started <route>
(rest://get:/...)`, pubsub/timer routes work, probes stay green. Two behaviours
make it fully silent — `addPlatformHttpListener` doesn't replay
`getHttpEndpoints()` to a new listener, and `addHttpEndpoint` swallows listener
exceptions at WARN. Nothing is logged for the failing requests because no route
runs.
*{*}Regression evidence{*}* (from the released jars' constant pools): 4.18.3
none → eager; 4.20.0 `@DependsOn` → eager; 4.21.0 `@Lazy`. Introduced by
`264db4c12e0`, titled {*}"Fix compilation error in camel-aws-s3 (#1783)"{*},
which replaced an `ObjectProvider<CamelContext>` with direct injection plus
`@Lazy`.
*{*}Reproduction{*}* is environment-dependent, so I described it honestly
rather than as a recipe: roughly 1 in 3 pods came up working, fixed per pod for
its lifetime (10/30 identical requests succeeded, from 3 healthy pods of ~9).
Apps with a separate management port don't see it — the management child
context initialises its DispatcherServlet early and
`beansOfTypeIncludingAncestors` instantiates the parent's mapping before Camel
starts. The deterministic check is the bean definition's `isLazyInit()`.
PR: https://github.com/apache/camel-spring-boot/pull/1874
> camel-platform-http-starter: CamelRequestHandlerMapping is @Lazy, so every
> platform-http endpoint can silently return 404
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24351
> URL: https://issues.apache.org/jira/browse/CAMEL-24351
> Project: Camel
> Issue Type: Bug
> Components: camel-platform-http
> Affects Versions: 4.21.0
> Reporter: Henrik
> Priority: Major
> Labels: regression, spring-boot
> Attachments:
> 0001-CAMEL-24351-camel-platform-http-starter-the-request-.patch
>
>
> `@Lazy` on the mapping bean means it is created on first demand, which is
> unordered against CamelContext startup. `CamelRequestHandlerMapping`
> registers itself as a `PlatformHttpListener` from its constructor, and
> `addHttpEndpoint` notifies only listeners existing at that moment — so if
> Camel starts first, the mapping receives no callback for any endpoint and its
> registry stays empty. Requests then get Spring's `BasicErrorController` 404,
> including the correct path, which is what makes it confusing to diagnose.
> The application looks healthy throughout: routes log `Started <route>
> (rest://get:/...)`, pubsub/timer routes work, probes stay green. Two
> behaviours make it fully silent — `addPlatformHttpListener` doesn't replay
> `getHttpEndpoints()` to a new listener, and `addHttpEndpoint` swallows
> listener exceptions at WARN. Nothing is logged for the failing requests
> because no route runs.
> *Regression evidence* (from the released jars' constant pools): 4.18.3 none →
> eager; 4.20.0 `@DependsOn` → eager; 4.21.0 `@Lazy`. Introduced by
> `264db4c12e0`, titled {*}"Fix compilation error in camel-aws-s3 (#1783)"{*},
> which replaced an `ObjectProvider<CamelContext>` with direct injection plus
> `@Lazy`.
> *Reproduction* is environment-dependent, so I described it honestly rather
> than as a recipe: roughly 1 in 3 pods came up working, fixed per pod for its
> lifetime (10/30 identical requests succeeded, from 3 healthy pods of ~9).
> Apps with a separate management port don't see it — the management child
> context initialises its DispatcherServlet early and
> `beansOfTypeIncludingAncestors` instantiates the parent's mapping before
> Camel starts. The deterministic check is the bean definition's `isLazyInit()`.
> PR: [https://github.com/apache/camel-spring-boot/pull/1874]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
