[ 
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.

 

Thanks.

> 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
(v7.6.3#76005)

Reply via email to