1- The current Sse feature enabling policy goes againt media type negotiation rules in all cases described below.
Also it's error prone and confusing since it lets user believe that a same resource can produce both text/event-stream and any standard media type (application/xml, applicaion/json ...)

• 1st case:

Let's consider following resource and a user request with Accept: application/xml, text/event-stream

   @GET
   @Produces(MediaType.APPLICATION_XML)
   public Response resourceMethod(@Context SseEventSink sseEventSink){
	   ...
   }

We are expecting the returned media type to be application/xml instead it will be text/event-stream.
More, SseFeature will be enabled although the resource method does not produce text/event-stream.

• 2nd case:

Let's consider following resource and a user request with Accept: application/xml;q=0.9, text/event-stream;q=0.5

   @GET
   @Produces({MediaType.APPLICATION_XML, MediaType.SERVER_SENT_EVENTS})
   public Response resourceMethod(@Context SseEventSink sseEventSink){
	   ...
   }

We are expecting the returned media type to be application/xml instead it will be text/event-stream.

• 3rd case:

Let's consider following resource and a user request with Accept: application/xml, text/event-stream

   @GET
   @Produces({"application/xml;qs=0.9", "text/event-stream;qs=0.5"})
   public Response resourceMethod(@Context SseEventSink sseEventSink){
	   ...
   }

We are expecting the returned media type to be application/xml instead it will be text/event-stream.

• 4th case:

Let's consider following resource and a user request with Accept: application/xml;q=0.9, application/json;q=0.5

   @GET
   @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON, MediaType.SERVER_SENT_EVENTS})
   public Response resourceMethod(@Context SseEventSink sseEventSink){
	   ...
   }

We are expecting the returned media type to be application/xml instead it will be text/event-stream.

2- The current Sse feature enabling policy inject SseEventSink instance and start asynch processing even if the resource medthod does not have any @Context SseEventSInk parameter.
So it leads to resource leaking since:

• the AsyncContext is never completed in case of real async processing (using org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher servlet class)
• or thread not being notified in case of "fake" async processing (using org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher servlet class)

Following resource is an example:

	@GET
	@Produces(MediaType.SERVER_SENT_EVENTS)
	public void resourceMethod() {
		...
	}

So in order not to be confusing for users and to be consistent with the existing media type negotiation rules (since it's not the goal of Sse feature to re-implement them) and also prevent resource leaking let's stick to the spec definition of a SSE resource method:

9.3 Server API
...
A resource method that injects an SseEventSink and produces the media type text/event-stream is an
SSE resource method.

and by saying "produces the media type text/event-stream" I"m wondering it means "only produces the media type text/event-stream" given the inconsistency of all previous cases above, the SseEventSink java doc and all example that can be found about JAX-RS Sse.