[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=16703227#comment-16703227 ] 

Tom Quarendon commented on ARIES-1867:

[~csierra], [~rotty3000], [~timothyjward]

So, to explain. We have a custom authentication module that allows you to have a "local" user, or have a user authenticated by, say, LDAP or kerberos. It's configuration is controlled by ConfigAdmin.

There is a REST API endpoint that allows you to change that configuration, so that we can implement a nice interface to it in the user interface. That REST API endpoint is exposed by a class that _purely_ relised on the ConfigAdmin service, nothing else. All it does is to get the configuration pid and change it.

The service that implements the authentication has an @modified method on it. This authentication service is necessarily a required service of the the REST API resource that performs login.

Despite the fact that we have an @modified method on the service, when we post the update to ConfigAdmin, the service is recycled. Curiously, it gets deactivated, reactivated again with the _original_ configuration, then the @modified method is called. Because it's reactivated the jaxrs whiteboard rewires things and we see a 404 from a subsequent request.

So we're not deliberately changing the config of something that is a required service of the endpoint doing the configuration, if you see what I mean. 

So far I haven't had time to investigate why the service is being recycled in the way that it is. That's nothing to do with the jaxrs whiteboard. 

Then I need to do some experiments to establish what causes a rewiring of the jaxrs whiteboard.

I suspect I'll then have to change some (all?) of the required service references in any REST API endpoints to "optional/dynamic" ones, and return a "service unavailable" if they aren't there. That way, hopefully, the actual REST API endpoints won't change, and, hopefully, jaxrs whiteboard won't decide that it needs to rewire and take everything offline.

As I say, I need to do more experimentation, but haven't had time yet.

When I do, this isn't the appropriate forum. What's a better one? What's the best forum for aries jaxrs whiteboard discussions? [user@xxxxxxxxxxxxxxxx|http://mail-archives.apache.org/mod_mbox/aries-user/]?

> 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