As we define an international standard which is covered by a TCK I would love to see this use case covered by the spec PDF and the TCK. Only that will guarantee that in the end it will really work. :-)
-Markus
From: Santiago Pericasgeertsen [mailto:santiago.pericasgeertsen_at_oracle.com]
Sent: Freitag, 3. Februar 2017 15:58
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: [jax-rs-spec users] Question on SSE API
On Feb 2, 2017, at 6:35 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
Experts,
we often see legacy JaveEE code in production that uses message-inflow by non-JAX-APIs, for example clouds sending notifications by AMQP (hence JMS), or on-premise systems sending notifications by JCA, or Swing Clients sending change notifications by IIOP or SOAP (hence remote EJB), or session bean timers are firing and so on.
In case a JAX-RS client shall be notified about such incoming events by means of SSE, how can such non-JAX-RS event sources forward their information into a JAX-RS SSE publisher?
Example: In a cloud scenario, a message driven bean is firing up because it received an AMQP event. In turn JAX-RS clients shall be informed.
Theoretically, this should be possible using CDI events: the JAX-RS endpoint would defined an @Observes method, and the other bean (whatever it is as long as it is CDI) should fire (forward) the event to it.
Not sure if this all works in practice, hence why I started with “theoretically” :-) I agree this a common use case.
— Santiago