[
https://issues.apache.org/jira/browse/CAMEL-22874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18053713#comment-18053713
]
Bjorn Beskow edited comment on CAMEL-22874 at 1/23/26 6:18 AM:
---------------------------------------------------------------
Thanks!
Once we have had time to stop and breathe for a while, I'll write up a couple
of blog posts on our company blog to summarize our experiences. It has
certainly been a challenging journey, with a fair amount of surprises. They
have mostly been related to infrastructure (the on-prem Kubernetes hosting has
been quite a ride), but the Mule-to-Camel migration turned out really
straight-forward. The structural similarity between them, being based on the
same solid abstractions, made Camel the obvious choice for the new platform.
We spent a lot of time up front getting a technology-agnostic regression test
harness in place (based on regular JUnit tests in combination to Testcontainers
and various Mocking frameworks for all external systems and technology
involved). It was based on the bitter observation that the customer's 15 years
of investment in Mule-based integration tests was of no value when we removed
Mule from the equation. We didn't want to go down that route again, hence we
use the Camel-specific test support solely for smaller white-box tests. The
bulk of the integration contract tests are graybox-type that rely only on the
foundational technologies. Hopefully that will still be usable if we for some
reason need to do this journey once more.
was (Author: beskow):
Thanks!
Once we have had time to stop and breathe for a while, I'll write up a couple
of blog posts on our company blog to summarize our experiences. I has certainly
been a challenging journey, with a fair amount of surprises. They have mostly
been related to infrastructure (the on-prem Kubernetes hosting has been quite a
ride), but the Mule-to-Camel migration turned out really straight-forward. The
structural similarity between them, being based on the same solid abstractions,
make Camel the obvious choice for the new platform.
We spent a lot of time up front getting a technology-agnostic regression test
harness in place (based on regular JUnit tests in combination to Testcontainers
and various Mocking frameworks for all external systems and technology
involved. It was based on the bitter observation that the customers 15 years of
investment in Mule-based integration tests was of no value if you remove Mule
from the equation. We didn't want to go down that route again, hence we use the
Camel-specific test support solely for smaller white-box tests. The bulk of the
integration contract tests are graybox-type that relies only on the
foundational technologies. Hopefully that will still be usable if we for some
reason need to do this journey once more.
> Error handler in openapi-contract-first route is invoked twice
> --------------------------------------------------------------
>
> Key: CAMEL-22874
> URL: https://issues.apache.org/jira/browse/CAMEL-22874
> Project: Camel
> Issue Type: Bug
> Components: camel-rest-openapi
> Affects Versions: 4.14.3, 4.17.0
> Reporter: Bjorn Beskow
> Priority: Minor
> Fix For: 4.14.5, 4.18.0
>
> Attachments: openapi-contract-first.zip
>
>
> Starting with 4.14.3, a defined error handler in a route which uses a
> openapi-contract-first endpoint gets invokes twice (which of course is
> annoying with duplicate logs but can also cause more severe problems if the
> error handling have side effects besides logging).
>
> The simplest way I found to reproduce the error was using the
> camel-spring-boot-examples/openapi-contract-first project:
> Add an error handler to the PetStoreRoute, which produces a log:
>
> {code:java}
> onException(Exception.class)
> .log("Error processing request: ${exception.message}")
> .handled(false); {code}
>
> Modify the GET route to throw an exception:
>
> {code:java}
> from("direct:getPetById")
> .process(e -> {
> throw new RuntimeException("Simulated error get pet");
> });
> {code}
>
> Start the application with spring-boot:run, then trigger the endpoint:
> {code:java}
> curl http://0.0.0.0:8080/myapp/myapi/pet/123 {code}
> The log statement of the exception handler shows up twice (as well as the
> Failed delivery logging).
>
> The problem seem to have started with version 4.14.3 (4.14.2 does not show
> this behavior).
>
> I have tried to debug the problem, but have too narrow knowledge about the
> code base to be of any help (sorry!)
>
> Attached is a simplified project based on
> camel-example-spring-boot-openapi-contract-first, with an integration test
> added that exposes the problem.
> Change the <camel-version> in pom.xml back to <= 4.14.2, and the problem
> disappears.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
