We don't currently support automatically starting REST-AT transactions. We decided against that because the service that creates coordinators (aka begin a transaction) could reside anywhere on the network.
I guess we could check to see if the current container has such a service deployed and if it did then start a "local" REST-AT transaction. But then we would need an api to expose the resulting urls to the service method.
Related is our support for an inbound bridge:- if a JAX-RS service method is annotated as transactional and the incoming http request has a link header containing a REST-AT transaction enlistment url then we will make sure that any JTA work performed by the service call becomes part of the REST-AT transaction.
John, is your requirement to simply have transactional JAX-RS services. If so then you just need to add JTA 1.2 transaction annotations to your JAX-RS service methods and you do not need to use REST-AT
Thanks for the explanation. Our use case would be that a Stateless Bean(in this case a REST one) would be called by a client and we did not want the client to be "burdened" by having to know that a REST-AT transaction needs to take place.
Regarding your last comment the idea of using REST-AT is because we want to manage transactions among different microservices which may reside in different app servers. In our monotithic, JBoss-based application, we use extensively CMT (using JTA annotations) in our stateless beans(REST and non-REST ones).
Michael, is there a link to learn about the inbound bridge you talk about?
If you have any other suggestions or ideas about how we can improve the usablitly of REST-AT please let us know.