Jakarta Connectors™ Architecture support in Quarkus

[George Gastaldi]

In some cases, integration with other systems (JMS servers, Mainframes, etc) is implemented using JCA Resource Adapters (RA).  For those cases, I have developed a Quarkus JCA extension[1] which manages the RA lifecycle and provides some services (WorkManager, Transactions, etc) in Quarkus. It’s still an early prototype but you can see that it works with the Artemis Jakarta RA (as you can see in the integration-tests[2] module). It takes advantage of some existing extensions, like ArC for the CDI and Narayana-JTA for integration with the Quarkus Transaction manager.

Before promoting it to the Quarkiverse organization and improving the docs, I’d really appreciate it if you could give it a try and send your (positive or negative) feedback in this thread. 

Best Regards,  

[1] - https://github.com/gastaldi/quarkus-jca

[2] - https://github.com/gastaldi/quarkus-jca/blob/main/integration-tests/pom.xml#L25-L29

Best Regards,

George Gastaldi

[hantsy bai]

Great work, George!

A question here, what's the difference between Jakarta Resource Connector and MP Reactive Messaging connectors, is there some common concept to adapt external resources ?

---

Regards,

Hantsy Bai

Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker

GitHub: https://github.com/hantsy

Twitter: https://twitter.com/@hantsy

Medium: https://medium.com/@hantsy

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/375A6511-7941-46C0-97C3-EBD60F9FBE23%40redhat.com.

[George Gastaldi]

Hey Hantsy,

Although JCA enables connecting to messaging systems, it’s not the only supported use case. Because JCA exists for ages (and the spec hasn’t changed much since its conception), I see the MP Reactive Messaging connectors as an evolution to connecting to messaging systems and should be preferred when possible. 

  

Best Regards,

George Gastaldi

[Max Rydahl Andersen]

Hi George,

Looks interesting - I now spotted https://github.com/quarkiverse/quarkus-ironjacamar - is this the same/different - did you move to use ironjacamar directly instead? (makes sense just understood that there were some downsides in picking up ironjacamar?)

/max

[George Gastaldi]

Hi Max,

Yes, I did. Although we can't use the WorkManager implementation because it depends on a really old JBoss Threads version, IronJacamar implements ConnectionManager pooling and transaction integration beautifully, that's why I decided to use it.

Also it kinda matches the scheme that we use the implementation in the name of the extension instead of the spec (eg. quarkus-hibernate-orm instead of quarkus-jpa)

[George Gastaldi]

For the record, I have asked the team to split the ironjacamar core module into more fine grained modules: https://github.com/ironjacamar/ironjacamar/issues/779

[V. Sevel]

> I’d really appreciate it if you could give it a try and send your (positive or negative) feedback in this thread. 

I meant to answer earlier. but this is a very welcomed extension for us.

for different reasons, we are not going to be able to ditch our horneq brokers for a while.

we started using the quarkus artemis extension with the messaging pool, but the ability to rebalance inbound connections based on topology is something very important for us.

and the artemis resource adapter does just that, plus provides transparent pooling for producers and consumers.

having ironjacamar in quarkus is going to allow us using the RA, and get the proper behavior.

a great great thank you, George, for making this happen. this was a very pleasant experience.

v.

[George Gastaldi]

Hey Vincent,

Thanks for your feedback, it was my pleasure to bring JCA support to Quarkus :) 
Now that quarkus-ironjacamar 1.0.0 is out , I think we can work with the quarkus-artemis extension maintainers to provide an additional extension there using the RA.

Best Regards, 

George Gastaldi

[V. Sevel]

yes that would be great. in the meantime we will start exercising it with our own integration.