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: |
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>
| <artifactId>camel-quarkus-examples-amq-broker-keycloak</artifactId> | ||
| <groupId>org.apache.camel.quarkus.examples</groupId> | ||
| <version>3.37.0-SNAPSHOT</version> | ||
| <version>3.35.0</version> |
There was a problem hiding this comment.
Following the next release, this version should be 3.36 ?
There was a problem hiding this comment.
If the PR targets the camel-quarkus-main branch then the version should be 3.37.0-SNAPSHOT.
| 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 ?
| ---- | ||
| $ docker run --name artemis_amq_demo -d -p 61616:61616 -p 8161:8161 \ | ||
| -e AMQ_USER=admin -e AMQ_PASSWORD=admin \ | ||
| quay.io/artemiscloud/activemq-artemis-broker:latest |
There was a problem hiding this comment.
For docker related commande lines, maybe pinning to explicit versions would be preferred to latest ?
There was a problem hiding this comment.
Should also use quay.io/arkmq-org/activemq-artemis-broker.
|
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?
jamesnetherton
changed the title
4 participants
This example demonstrates integration of Apache ActiveMQ Artemis (AMQ Broker) with Keycloak authentication in a Camel Quarkus application.
Features:
The example supports: