6 Replies Latest reply on Feb 24, 2020 7:13 AM by ochaloup

    Asynchronous handling for Narayana CDI extension


      Hi tomjenkinson and mmusgrov,


      I would need to check with you how to integrate the asynchronous handling for Narayana CDI extension. As the WildFly is about to support the MicroProfile specs the context propagation is one of them. I started to talk about it with kabirkhan.


      Kabir started with integration of WildFly and the MicroProfile context propagation. The issue we've disscused was the asynchronous handling for transactions.

      The Quarkus managed it with adding this code

      quarkus/TransactionalInterceptorBase.java at master · quarkusio/quarkus · GitHub

      on top of the code available in Narayana interceptor.

      narayana/TransactionalInterceptorBase.java at master · jbosstm/narayana · GitHub


      The code in Quarkus depends on the org.reactivestreams and on the io.smallrye.reactive.converters. My initial idea was that the code dependent on the reactive features could be part of the WFLY integration. And Narayana interceptor would then only inject that functionality e.g. via CDI.

      But my attempts to cleanly separate the functionality did not go well. The quarkus code is coupled on both sides. You can check the attempt here.

      Comparing master...async-handling-from-quarkus · ochaloup/narayana · GitHub


      Then now I support the idea to make the Narayana dependent to that reactive libraries. All the code which is currently in Quarkus will be moved to Narayana. But the reactive libraries won't be required during runtime. When the reactive features are not available on classpath then they won't be used.

      Additional advantage would be that Narayana code may could be potentially used directly in Quarkus. The CDI interceptor code would not be duplicated there.


      Please, what is your perspective on this?