> On Feb 3, 2017, at 12:31 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
>
> 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. :-)
Sounds to me like you are volunteering ;-)
— Santiago
> <>
> 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 <mailto: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