On 10/20/2015 4:36 PM, Markus KARG wrote:
> In fact I did never propose "SSE over CDI".
>
> What I said was simply that I do not want to have another _JAX-RS-specific_ API simply for synchronizing a waiting party and a sending party. CDI events are THE common solution for this kind of design problem. There is no good reason to reinvent the wheel just for the SSE case.
>
> Using CDI you can declare that there is a listener method to be fired whenever an event of a particular type is fired. Both, the listener and the firing party of the CDI event, can be any Java EE component -- including, but not limited to JAX-RS resources. So it makes to sense to provide another solution, which only works within JAX-RS, and particularly only with SSE, but not with other pushing technologies possibly added later or by third parties.
>
> The correct API design would be that the JAX-RS resource sends a SSE data message in reaction to a CDI event, and it can (just like all other Java EE components) fire a CDI event from within a JAX-RS resource (or any other JAX-RS component).
>
CDI is component to component events intra-VM. SSE is pushing/receiving
events from the network. JAX-RS is a protocol to Java mapper. The
whole point of JAX-Rs is to declaratively map request and responses to
HTTP. I actually don't kno how CDI could fit as you want to control
*exactly* how data is mapped to the outgoing SSE event, or unmarshalled
from an incoming one.
This is why I wanted to know how SSE over CDI would look and how you
would define this mapping between CDI and HTTP/SSE.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com