Using jta 1.2 and @Transactional it would if the consumer impl wpuld. Means it will not for kafka but it is true of a connector as well until you fake the tx/persistence.
See connectors as a default interceptor stack, cdi provides a customizable one by design. This is why jca will no more be mainstream IMHO. Le mer. 1 août 2018 17:56, David Jencks <[email protected]> a écrit : > Does the CDI approach support consuming a message inside a transaction? > Looking at one of the Kafka cdi examples, I didn’t immediately see how it > would. Being able to roll back the consumption of a message always seemed > one of the main points of jca to me. > > Thanks > David Jencks > > Sent from my iPhone > > > On Jul 31, 2018, at 9:59 PM, Romain Manni-Bucau <[email protected]> > wrote: > > > > I am happy to help you using the rar if you can setup a reproducer > project > > but for kafka gain is pretty low and being cdi based opens more doors > like > > composing with decorators, getting a better error handling than EJB, > > getting rid of some useless layer for kafka etc...but we can still do the > > exercise technically :) > > > > Le mer. 1 août 2018 02:00, ChrisOwens <[email protected]> a écrit : > > > >> Romain Manni-Bucau wrote > >>> If your goal is really to interact with kafka - and you dont care of > rar > >>> by > >>> themselves - i would recommand to use a cdi extension, > >>> you can find several on the net like > >>> https://github.com/bgjug/kafka-cdi-extension and > >>> https://github.com/aerogear/kafka-cdi > >> > >> > >> Thank you. I was hoping to use the message-driven-bean abstraction, > but I > >> will look into these cdi extensions instead. > >> > >> > >> > >> > >> -- > >> Sent from: > >> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html > >> >
