Add AMQ Broker and Keycloak integration example#511
Conversation
|
The platform version should probably be upgraded after the recent release of the camel-quarkus main branch: |
JinyuChen97
force-pushed
the
CEQ-9957
branch
2 times, most recently
from
0906ed2 to
e322d40
Compare
| public Map<String, String> getConfigOverrides() { | ||
| return Map.of("jdk.tls.namedGroups", "X25519MLKEM768"); | ||
| public void configure() { | ||
| from("cxf:bean:inventoryService") |
There was a problem hiding this comment.
Are we forced to use CXF to demo keycloak policy ? Would cxf brings an extra complexity layer for the user to understand or it's ok ?
There was a problem hiding this comment.
The requirement of this example mentioned that nice to include REST and SOAP service. Waiting comment from Ivo and Torsten to see if this REST -> SOAP example flow is fine.
|
Looks a great start, generally speaking, there is a question whether the example could be less verbose ? Like do we really need equals method ? Do we really need that much properties in domain pojos ? The ideal situation would be that each new lines introduced serves the demo purpose as much as possible. So that, users learning camel are not lost into details and complexities that could live in their own example documetation... Does it make sense ? it's open for discussion for sure :) |
| %test.soap.inventory.client.address=http://localhost:8081/services/inventory | ||
|
|
||
| # Native Configuration | ||
| quarkus.native.additional-build-args=--initialize-at-run-time=org.springframework.jms.listener.AbstractMessageListenerContainer$ObservationFactory |
There was a problem hiding this comment.
Is this definitely needed? If so we need to investigate why.
There was a problem hiding this comment.
you mean the quarkus.native.additional-build-args=--initialize-at-run-time=org.springframework.jms.listener.AbstractMessageListenerContainer$ObservationFactory?
yes, it is needed when I ran the native test, it throwed the following error:
Error: Class initialization of org.springframework.jms.listener.AbstractMessageListenerContainer$ObservationFactory failed caused by: java.lang.ClassNotFoundException: io.micrometer.jakarta9.instrument.jms.JmsProcessObservationConvention, do we need to fix this in camel quarkus?
There was a problem hiding this comment.
do we need to fix this in camel quarkus?
Would be good to understand why the issue happens in this example and why we don't see it in the JMS integration tests run in the main Camel Quarkus project
If it turns out to be a pain to fix / investigate, then we can just open an issue in the Camel Quarkus project and then link to it here via a TODO comment in application.properties.
There was a problem hiding this comment.
Hmm, it looks like an issue to work with micrometer and can you find the dependencies at the runtime and maybe we can disable it?
There was a problem hiding this comment.
After investigation by using quarkus.native.additional-build-args=-H:+PrintClassInitialization, This issue seems triggered by the cxf-soap + jms combination in native mode. During native image build, Quarkus's JaxbProcessor scans @XmlRootElement annotations on Camel route definitions. because of CXF is there, this creates a deep reference chain: CxfEndpoint → JmsEndpoint → AbstractMessageListenerContainer → ObservationFactory (inner class). GraalVM then initializes ObservationFactory at build-time, execute it's static block which requires DefaultJmsProcessObservationConvention from micrometer-jakarta9.
JMS integration tests don't have this issue because they don't use CXF. Without CXF, the scanning is shallow and ObservationFactory is not included. I also verified this by adding cxf-soap dependency to the jms-jpa example, and it reproduced the same error. Please correct if im wrong. and also Is this kind of issue caused by combination need to be fixed in camel quarkus project? or need to mentioned somewhere?
There was a problem hiding this comment.
Ok - I actually thought we fixed those kinds of issue.
The acceptable workaround for now will be to add camel-quarkus-jaxb to the project and I'll think of a better solution for the Camel Quarkus core project for the future.
jamesnetherton
changed the title
This example demonstrates integration of Apache ActiveMQ Artemis (AMQ Broker) with Keycloak authentication in a Camel Quarkus application. Features: - REST endpoint for order submission with Keycloak authentication - SOAP endpoint for inventory management with Keycloak security policy - JMS integration using AMQ Broker for asynchronous order processing - Admin endpoint with role-based access control (RBAC) - Keycloak component for user management The example supports: - Development mode with Dev Services (auto-start Keycloak and Artemis) - JVM mode - Native mode - Kubernetes deployment with complete YAML manifests and testing guide Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> On-Behalf-Of: Jinyu Chen <as0830428946@gmail.com>
thanks for the advice! I have simplify some domain objects, processor... Currently waiting for the feedback from Ivo or Torsten to see if this REST -> SOAP example is fine. |
|
Heads up that some versions across all other projects have been updated:
Please ensure this project is updated to be in sync. |
4 participants
This example demonstrates integration of Apache ActiveMQ Artemis (AMQ Broker) with Keycloak authentication in a Camel Quarkus application.
Features:
The example supports: