Better Integration with camel

[turing85]

As a user of the extension io.quarkiverse:quarkus-artemis-jms who also uses camel

when I define ConnectionFactorys via a configuration file (application.properties/application.yml)

then I want that that those ConnectionFactorys are automatically registered in the camel context, so that I can use them via their name, e.g.:

from(jms("queue:in").connectionFactory("<default>"))
    .to(jms("queue:out").connectionFactory("named"));

---

As a user of the extension io.quarkiverse:quarkus-artemis-jms who also uses camel

when I define ConnectionFactorys as beans in my application that have an @io.smallrye.common.annotation.Identifier("...")

then I want that that those ConnectionFactorys are automatically registered in the camel context, so that I can use them via their name, e.g.:

from(jms("queue:in").connectionFactory("named"))
    .to(jms("queue:out").connectionFactory("externally-defined"));

---

As a user of the extension io.quarkiverse:quarkus-artemis-jms who also uses camel

when I use only one ConnectionFactory (either through configuration or externally defined)

then I want that this connection factory is registered automatically, and I do not have to set it explicitly, e.g.:

from(jms("queue:in"))
    .to(jms("queue:out"));

[zhfeng]

Thanks @turing85 and I think the case 1 and case 3 should be supported in camel-quarkus-jms already. It could register all the beans from quarku-arc container automatically. In case 2, if @Identifier is recognized as bean, it should be good too. So I wonder if all the integration tests with camel-quarkus-jms could be moved to camel-quarkus/integration-tests/jms-artemis-client to see if they pass.

[turing85]

@zhfeng

For case 3, I am quite sure that it is only supported for externally defined connection factories, as well as the default connection factory, but not for a single, named connection factory (whether this "feature" will be used extensively in this form is another topic, having a homogenous default behaviour, however, is desirable in my opinion).

I tested for case 1 beforehand without modification, and it did not work. I also tested by "just adding" @Named(...) annotations to the synthetic beans; did not work either. I can re-try these tests without the CamelContextEnhancer, but I think the tests will fail.

With regards to the tests: I'd like to have some tests on our end to verify we do not release something that breaks the camel-integration. I will, however, provide additional tests to quarkus-camel.

[turing85]

For more details on case 1 and 3, see this, this and this comment.

Short summary: as of now, all parts implemented in this enhancement are needed; none of them are automated by camel.

[zhfeng]

Hi @turing85

I think this could be similar with https://github.com/apache/camel-quarkus/issues/4063. We add the @Identifier Qualifier, and it makes looking for ConnectionFactory bean failing. So I think we have to register a CamelBeanQualifierResolverBuildItem such like https://github.com/apache/camel-quarkus/blob/main/extensions-support/jdbc/deployment/src/main/java/org/apache/camel/quarkus/support/jdbc/deployment/JdbcSupportProcessor.java#L37

I will figure it out.

[zhfeng]

Well, the root cause is that we was missing configurator.name(name); in ArtemisJmsProcessor.java. After adding it, all the camel-jms tests should work.

[zhfeng]

@turing85 Please check https://github.com/quarkiverse/quarkus-artemis/pull/125

[zhfeng]

And for case 2 it also need @Named("externally-defined") to make the ConnectionFactory to be looked up for camel-quarkus registry.

[turing85]

125 was closed. We added .name(...)s to the created ConnectionFactorys (https://github.com/quarkiverse/quarkus-artemis/pull/122/commits/a4715297125215d60329f21e35f09ab80d8995d6) and a property to enable CamelContextEnhancer (https://github.com/quarkiverse/quarkus-artemis/pull/122/commits/77bb9a2d9d47dd0e0b8937fd1a9e667ed840b82c )