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


Reply via email to