[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16699440#comment-16699440
]
Tom Quarendon commented on ARIES-1867:
--------------------------------------
[~rotty3000] Yes, I just @Ignored things that didn't work.
[~csierra] I must apologise. There's no general problem with the
ContainerResponseFilter and void methods. I jumped to conclusions there. My
problem is a bit more subtle. I am actually getting 404 from the endpoint,
which is being reported as a CORS failure by the browser.
The issue is that we have a case where two PUTs are made by our user interface,
one after another. They both change some configuration. The first has the
effect of modifying the configuration of a component that is then a required
reference of the component providing the second endpoint. So the first request
is made, and it has the effect of recycling the component providing the second
endpoint, hence when the second request comes in it isn't there, hence 404. So
our bad for the way we've coded things (no @Modified method, perhaps not using
optional references etc to ensure that the jaxrs resource classes don't
recycle).
The reason we didn't see it before is that we'd coded a "recycle delay" into
our jaxrs whiteboard. So to avoid churn, and poor performance, on startup, we
had a delay such that it would only reconfigure the jaxrs servlet if there were
no component activations/deactivations for, say, 150ms. Since on startup you
get a storm of resource classes activating, it seemed unnecessary to completely
reconfigure the jaxrs servlet with each one, and it was leading to a poor
startup. Having added some System.out.printlns to the Aries jax-rs whiteboard
code, it looks like you reconfigure with each component
activation/deactivation, but it doesn't seem to cause performance problems.
I'll have to do some code review to look for cases where there might be issues
caused by this, but I don't consider this a bug in the jaxrs whiteboard, just a
behaviour to understand.
So the SSE example seems to be the special case, and I can (and have) worked
round that as our use of that is limited and I've just manually added the CORS
headers where necessary.
> 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: Blocker
> Attachments: CORSFilter.java, Server.java, TestService3.java
>
>
> 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)
