Re: FW: [jersey/jersey] SseEventSink invokes custom WriterInterceptor with wrong type, then throws NPE (#3592)

Sergey Beryozkin

Hi Pavel

So, when the SSE server reports a new event which will need to be delivered to SSE Client in for ex JSON, MessageBodyWriter is supported, right ?
I'm not understanding why WriterInterceptor is not supported in this case to keep it consistent with the regular response case.

I agree one can write a custom MessageBodyWriter with injected @Providers - believe it or not but I'm nearly 100% sure this is what I used as an argument against introducing Reader/Writer interceptors back in 2.0 :-). Everything you can do with WriterInterceptor can most likely be done with the custom MBW.

But we do have WriterInterceptor now so it is not clear why not just let users use them with SSE too

Cheers, Sergey

On 27/06/17 06:42, Pavel Bucek wrote:


yes, the issue is that mostly, you wouldn't want to mix "standard" response processing and SSE.

MessageBodyWriter is slightly different, since there is a type, the ultimate definition of that provider, which can be used for lookup and the registered provider won't have any consequence on running app, unless used as a return type. WriterInterceptor doesn't have anything like that - how would you mark the provider as "please use it only with some particular EventSink"? Also, if we'd think about symmetry - that would mean that we need to invoke ReaderInterceptor per each received client event.

EventSink is not a resource method, we have almost no control of the context from which it is invoked from. Allowing MessageBodyWriters to be invoked is a simplest enhancement compared to "writing only strings". Server sent event is supposed to be lightweight and cheap to send - notice that it doesn't need to be used, writing a string is still supported.

And your usecase - WriterInterceptor is not what you want to use in described scenario. You can implement a MessageBodyWriter, unwrap, lookup the MBW for the type you've unwrapped using injected Providers instance.


On 26/06/2017 21:45, Markus KARG wrote:



I know this is really late to discuss, but in fact, I doubt that it was a good decision to take WriterInterceptor out of the processing chain for SSE events.


In fact, today I set up a demo app and needed this, so I actually thought that this is a Jersey bug…!


Is there any good technical reason that made us strip WriterInterceptor from the processing chain (see below commit)?


Scenario where this is a problem: I wanted to add support for Optional<T> to demonstrate Java 8 support of JAX-RS. So I set up a WriterInterceptor which simply unwraps Optional to produce T, so all existing pre-2.1 EntityWriters for T will still work. Great. But fails with SSE! Hence, one must rewrite all WriterIntercepors if support for Optional<T> is needed with SSE. Very bad thing!


Why don't we use WriterInterceptors with SSE events?





From: Pavel Bucek [mailto:notifications@...]
Sent: Montag, 26. Juni 2017 09:38
To: jersey/jersey
Cc: Markus KARG; Author
Subject: Re: [jersey/jersey] SseEventSink invokes custom WriterInterceptor with wrong type, then throws NPE (#3592)


Please see this: jax-rs/spec@b4b0d91

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Join to automatically receive all group messages.