I’m not aware of any sanctioned way to ‘detect’ what runtime the client library is running in, and therefore I would not advise a technical solution to that section of the specification. As JB mentioned, users need to be aware of this.
Also, this might be worth opening a ticket with Jakarta JMS to see if the Callback may be used with an asynchronous servlet request. I suspect the core issue is around thread lifecycle not being guaranteed with sync servlet requests, but if the originating request comes in via asynchronous servlet request, perhaps changing two asynchronous callbacks is fine. This feels like it can be addressed best as a developer usage documentation note on the https://activemq.apache.org/jms2 page. Matt Pavlovich > On Dec 7, 2024, at 4:05 PM, Ken Liao <kenlia...@gmail.com> wrote: > > Hi dev community, > > According to > https://jakarta.ee/specifications/messaging/3.1/jakarta-messaging-spec-3.1#restrictions-on-usage-in-jakarta-ee > Asynchronous send is not permitted in a Jakarta EE web container or > Enterprise Beans container. However, This is recommended but not required. > I have spent some time trying to find precedent for disabling a feature in > those environments in the codebase but couldn't. > > Is there any precedent for turning off a particular feature in a Jakarta EE > web container or Enterprise Beans container in ActiveMQ Classic? If not, > can we skip that requirement for implementing Jakarta 3.1 async send? > > Thanks, > Ken --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org For additional commands, e-mail: dev-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact