[ 
https://issues.apache.org/jira/browse/CXF-8215?focusedWorklogId=395387&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-395387
 ]

ASF GitHub Bot logged work on CXF-8215:
---------------------------------------

                Author: ASF GitHub Bot
            Created on: 29/Feb/20 03:18
            Start Date: 29/Feb/20 03:18
    Worklog Time Spent: 10m 
      Work Description: reta commented on pull request #643: CXF-8215: SSE 
breaks Pipeline Processing
URL: https://github.com/apache/cxf/pull/643
 
 
   
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


Issue Time Tracking
-------------------

    Worklog Id:     (was: 395387)
    Time Spent: 20m  (was: 10m)

> SSE breaks Pipeline Processing
> ------------------------------
>
>                 Key: CXF-8215
>                 URL: https://issues.apache.org/jira/browse/CXF-8215
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>            Reporter: Markus Rathgeb
>            Assignee: Andriy Redko
>            Priority: Major
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> Hi,
> I am using the Aries JAX-RS Whiteboard implementation that is using CXF 
> internally.
> I realized a behavior that does not match my expectation, so I checked the 
> JAX-RS specification and IMHO the current behavior is wrong.
> I opened an issue for Aires JAX-RS Whiteboard and have been told that it 
> should be filled for CXF.
> I could copy the whole initial description of the other issue to this one or 
> link it (https://issues.apache.org/jira/browse/ARIES-1968)... I assume that 
> all information should be added to the issue for the specific project, so I 
> copy it:
>  
> The JAX-RS Specification 2.1 contains the chapter 9 for "Server-Sent Events".
> The chapter 9.5 "Pipeline Processing" declares:
> {quote}For compatibility purposes, implementations MUST initiate processing 
> of an SSE response when either the first message is sent or when the resource 
> method returns, whichever happens first. The initial SSE response, which may 
> only include the HTTP headers, is processed using the standard JAX-RS 
> pipeline as described in Appendix C. Each subsequent SSE event may include a 
> different payload and thus require the use of a specific message body writer. 
> Note that since this use case differs slightly from the normal JAX-RS 
> pipeline, implementations SHOULD NOT call entity interceptors on each 
> individual event (1).
> {quote}
> So, the initial SSE response is processes using the standard JAX-RS pipeline 
> (Appendix C).
> Appendix C indicates that in front of the method invocation the "Container 
> Request Chain" is handled and after the method invocation the "Container 
> Response Chain" is handled.
>  
> The container response chain is currently not handled for the first response!
> It is also not handled for the other reponses, but this is expected.
>  
> I checked v1.0.5, v1.0.6 and v1.0.7 all seems to be broken for me.
>  
> h2. Test code:
>  
> {code:java}
> @Component(service = Application.class)
> @JaxrsName("rest")
> @JaxrsApplicationBase("rest")
> public class RESTApplicationImpl extends Application {
> }{code}
>  
>  
> {code:java}
> @Component(service = { RESTResource.class })
> @JaxrsResource
> @JaxrsName("foo")
> @JaxrsApplicationSelect("(" + JaxrsWhiteboardConstants.JAX_RS_NAME + "=rest)")
> @Path("/foo")
> public class RESTResource {
> @GET
>  @Path("normal")
>  public Response normal() {
>  System.out.println("handle endpoint \"normal\"");
>  return Response.ok().build();
>  }
> @GET
>  @Path("sse")
>  @Produces(MediaType.SERVER_SENT_EVENTS)
>  public void sse(@Context final SseEventSink eventSink, @Context final Sse 
> sse) {
>  System.out.println("handle endpoint \"sse\"");
>  final ExecutorService executor = Executors.newSingleThreadExecutor();
>  executor.execute(() -> {
>  try (SseEventSink sink = eventSink) {
>  eventSink.send(sse.newEvent("event1"));
>  eventSink.send(sse.newEvent("event2"));
>  }
>  });
>  executor.shutdown();
>  }
> }
> {code}
>  
>  
> {code:java}
> @Component
> @JaxrsExtension
> @JaxrsApplicationSelect("(" + JaxrsWhiteboardConstants.JAX_RS_NAME + "=rest)")
> public class SimpleRequestFilter implements ContainerRequestFilter {
> @Override
>  public void filter(final ContainerRequestContext context) {
>  System.out.println("simple request filter");
>  }
> }
> {code}
>  
>  
> {code:java}
> @Component
> @JaxrsExtension
> @JaxrsApplicationSelect("(" + JaxrsWhiteboardConstants.JAX_RS_NAME + "=rest)")
> public class SimpleResponseFilter implements ContainerResponseFilter {
> @Override
>  public void filter(final ContainerRequestContext requestContext, final 
> ContainerResponseContext responseContext)
>  throws IOException {
>  System.out.println("simple response filter");
>  }
> }
> {code}
>  
>  
> h2. Test:
> On a GET request to "http://127.0.0.1:8080/rest/foo/normal"; is see (on the 
> server console):
>  
> {noformat}
> simple request filter
> handle endpoint "normal"
> simple response filter{noformat}
>  
> On a GET request to "http://127.0.0.1:8080/rest/foo/sse"; is see (on the 
> server console): 
> {noformat}
> simple request filter
> handle endpoint "sse"{noformat}
>  
> As the normal processing pipeline must be applied for the first SSE reponse I 
> would expect "simple response filter" is shown once, too.
>  
> In my application there is a ContainerResponseFilter to allow (configurable) 
> CORS. If it is enabled, the headers that allow the cross-origin access are 
> added.
> This needs to be added to the initial header (first response) of the SSE 
> connection, too.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to