[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jira] [Commented] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint

    [ https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700754#comment-16700754 ] 

Tom Quarendon commented on ARIES-1867:

[~csierra] Can you explain to me the circumstances under which the JAX-RS whiteboard reconfigures? I'm afraid I can't follow the code, it relies on a bunch of other Aries things that at the moment I can't delve into.

Does it republish whenever it detects ANY service being deactivated or activated, regardless of whether the service is a resource of extension? (I've been printing out the list of classes in CxfJaxrsServiceRegistrator.rewire, and apparently seeing no changes sometimes). 

What happens to any requests that are received during the same time window as that republish operation occurs? Is there a window where the "old" endpoint is shutdown before the new one is created and wired in when requests that are received would return a 404?

I'm trying to find an explanation for a 404 response I'm seeing when one of my endpoints briefly seems to go missing. When I print out the list of resources in that "rewire" method the resource class always seems to be there, so I'm trying to understand where it's going.

Separately I'm trying to understand why some of my services are being deactivated and reactivated when their config changes, _despite_ having an @Modified method, which I think is contributing to the bouncing of the endpoints.



> ContainerResponseFilter not fired for SSE endpoint
> --------------------------------------------------
>                 Key: ARIES-1867
>                 URL: https://issues.apache.org/jira/browse/ARIES-1867
>             Project: Aries
>          Issue Type: Bug
>          Components: jax-rs-whiteboard
>    Affects Versions: jax-rs-whiteboard-1.0.2
>            Reporter: Tom Quarendon
>            Assignee: Carlos Sierra
>            Priority: Major
>         Attachments: CORSFilter.java, Server.java, TestService3.java, make.out, make2.out
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
>   private Sse sse;
>   private SseBroadcaster eventBroadcaster;
>   @Context
>   public void setSse(Sse sse) {
>     this.sse = sse;
>     this.eventBroadcaster = sse.newBroadcaster();
>   }
>   @GET
>   @Produces(MediaType.SERVER_SENT_EVENTS)
>   public void suscribeToEvents(@Context SseEventSink eventSink) {
>     eventBroadcaster.register(eventSink);
>   }
> }
> {code}
> In addition, I have a CORS filter:
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
>   @Override
>   public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) throws IOException {
>     System.out.println("CORSFilter for "+requestContext.getUriInfo().getPath());
>     MultivaluedMap<String, Object> headers = responseContext.getHeaders();
>     headers.add("Access-Control-Allow-Origin", requestContext.getHeaderString("Origin"));
>     ...
> {code}
> The CORS filter gets fired on all requests as I expect, _except_ for ones to the EventResource.subscribeToEvents method. Hence browsers complain when receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level issue. I will try and come up with a plain CXF test of the same thing for comparison.

This message was sent by Atlassian JIRA