[jira] [Commented] (ARIES-1866) URI binding conflict resolution appears incorrect in jaxrs-whiteboard

[Tom Quarendon (JIRA)]

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

Tom Quarendon commented on ARIES-1866:
--

[~csierra] Yes, this fix seems to work, and my endpoints now get matches as I 
expect.

Thanks again for the fix. Happy for this to be closed.

> URI binding conflict resolution appears incorrect in jaxrs-whiteboard
> -
>
> Key: ARIES-1866
> URL: https://issues.apache.org/jira/browse/ARIES-1866
> Project: Aries
>  Issue Type: Bug
>  Components: jax-rs-whiteboard
> Environment: I'm using jax-rs whiteboard 1.0.1 on Windows, within 
> apache karaf.
>  
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: TestResource.java, TestResource2.java
>
>
> I'm seeing different behaviour in the URI resource binding conflict 
> resolution when using tje jax-rs whiteboard as then using "plain" cxf.
> Attached are two resource class implementations. One has a class level @Path 
> of "test", with then a subresource locator with an @Path of "\{a}" returning 
> another resource class that has a @GET with an @Path of "\{b}". 
> The other resource class has a class level @Path of "test/a/b". 
> Given a GET request for "/test/a/b" it should match the second of these 
> resource classes as being the most specific match. Instead it matches the 
> first. Indeed it seems that the presence of the first resource class stops 
> anything going to the second. If I change the @Path for the second resource 
> class to be "test2/a/b" then appropriate requests get routed there. 
> I have run a "plain" cxf test by adapting the CXF provided "basic" jax-rs 
> test with the same resource classes, and it routes as I would expect. 
> I had intended to try and adapt the example in the aries jaxrs whiteboard 
> project, but I get test errors when I run an "mvn install",and it isn't 
> obvious to me how the jax-rs._example_-run/_example_.jar file mentioned in 
> the readme would get created.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[Tom Quarendon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tom Quarendon updated ARIES-1867:
-
Priority: Major  (was: Blocker)

> 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
>
>
> 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 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)

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

[Tom Quarendon (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 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)

[jira] [Commented] (ARIES-1866) URI binding conflict resolution appears incorrect in jaxrs-whiteboard

[Timothy Ward (JIRA)]

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

Timothy Ward commented on ARIES-1866:
-

{quote}BTW, what kind of release timetable would there be to getting a 
non-snapshot release with this in?
{quote}
 

We were planning one this week, but will now spend a little more time trying to 
iron out the recently identified bugs. Assuming nothing catastrophic emerges I 
would expect to see a release in Maven Central before the end of the year, 
hopefully in the next couple of weeks.

> URI binding conflict resolution appears incorrect in jaxrs-whiteboard
> -
>
> Key: ARIES-1866
> URL: https://issues.apache.org/jira/browse/ARIES-1866
> Project: Aries
>  Issue Type: Bug
>  Components: jax-rs-whiteboard
> Environment: I'm using jax-rs whiteboard 1.0.1 on Windows, within 
> apache karaf.
>  
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: TestResource.java, TestResource2.java
>
>
> I'm seeing different behaviour in the URI resource binding conflict 
> resolution when using tje jax-rs whiteboard as then using "plain" cxf.
> Attached are two resource class implementations. One has a class level @Path 
> of "test", with then a subresource locator with an @Path of "\{a}" returning 
> another resource class that has a @GET with an @Path of "\{b}". 
> The other resource class has a class level @Path of "test/a/b". 
> Given a GET request for "/test/a/b" it should match the second of these 
> resource classes as being the most specific match. Instead it matches the 
> first. Indeed it seems that the presence of the first resource class stops 
> anything going to the second. If I change the @Path for the second resource 
> class to be "test2/a/b" then appropriate requests get routed there. 
> I have run a "plain" cxf test by adapting the CXF provided "basic" jax-rs 
> test with the same resource classes, and it routes as I would expect. 
> I had intended to try and adapt the example in the aries jaxrs whiteboard 
> project, but I get test errors when I run an "mvn install",and it isn't 
> obvious to me how the jax-rs._example_-run/_example_.jar file mentioned in 
> the readme would get created.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JIRA]

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

Raymond Augé commented on ARIES-1867:
-

[~tomq42] I have also experienced a race condition on that one test from time 
to time. We should fix it. Otherwise, tests should all be passing. If that's 
not the specific test you care about you may just want to @Ignore it for the 
time being.

> 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 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)

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

[Tom Quarendon (JIRA)]

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

Tom Quarendon commented on ARIES-1867:
--

[~csierra] I've been experimenting with your testVoidResourceWithFilter test.

Tomorrow I'll try and work out what's different for my case, or indeed whether 
I can reproduce the scenario I was seeing any more. I definitely had a simple 
@GET method that had a void return and wasn't having the CORS filter called. 
I'll try and translate that into a test case, now I have your framework test 
and can understand what it actually does.

BTW, would I expect all the other tests to run cleanly? I can't run "mvn clean 
install" cleanly from the root directory, I get test case failures in the 
ClassIntrospectorTest (testResourceWithSubresource and 
testPlainResourceSeveralOperationsWithCommonPath). I also get a test case 
failure in one of the integration tests (TEST 
testApplicationEndpointExtensionRuntimeDTO(test.JaxrsTest) <<< ERROR: 
expected: but was:).

 

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: 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 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)

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

[Carlos Sierra (JIRA)]

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

Carlos Sierra commented on ARIES-1867:
--

Hi again [~tomq42],

I have pushed a couple of tests to the whiteboard test suite showing the 
behaviour of the whiteboard w.r.t resources returning {{void}} results and 
{{ContainerResponseFilter}}. It seems that, in general, the whiteboard is 
properly registering the filters for the resources that return {{void}} but, as 
you found out, these filters are not invoked in the case of the SSE 
{{subscribe}} methods. Could you please verify these assumptions are correct?

My current assumption is that CXF is not handling these properly. I will try 
and verify that for the 3.2.5 version, which is the one that the whiteboard is 
currently using.

Thx for your report.

Bests.

Carlos.

> 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 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)

[jira] [Commented] (ARIES-1866) URI binding conflict resolution appears incorrect in jaxrs-whiteboard

[Carlos Sierra (JIRA)]

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

Carlos Sierra commented on ARIES-1866:
--

hey [~tomq42],

it looks like the whiteboard specification is a bit broad to this regard and 
the expected behaviour in this case it is not very well defined.

I have pushed a proposed fix in which resource services that do not specify 
{{service.ranking}} are considered equal and, thus, not ordered among 
themselves so JAX-RS rules should apply.

Before this fix the default {{ServiceReference}} order was applied, so service 
resource NEVER clashed because the {{ServiceReference}} ordering was applied.

We have also filed a proposal to ammend the spec and narrow down this expected 
behavior.

I have incorporated your tests to the JAX-RS test suite.

I have also released a new snapshot containing this fix. Could you please check 
this works for you?

Bests.

Carlos.

> URI binding conflict resolution appears incorrect in jaxrs-whiteboard
> -
>
> Key: ARIES-1866
> URL: https://issues.apache.org/jira/browse/ARIES-1866
> Project: Aries
>  Issue Type: Bug
>  Components: jax-rs-whiteboard
> Environment: I'm using jax-rs whiteboard 1.0.1 on Windows, within 
> apache karaf.
>  
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: TestResource.java, TestResource2.java
>
>
> I'm seeing different behaviour in the URI resource binding conflict 
> resolution when using tje jax-rs whiteboard as then using "plain" cxf.
> Attached are two resource class implementations. One has a class level @Path 
> of "test", with then a subresource locator with an @Path of "\{a}" returning 
> another resource class that has a @GET with an @Path of "\{b}". 
> The other resource class has a class level @Path of "test/a/b". 
> Given a GET request for "/test/a/b" it should match the second of these 
> resource classes as being the most specific match. Instead it matches the 
> first. Indeed it seems that the presence of the first resource class stops 
> anything going to the second. If I change the @Path for the second resource 
> class to be "test2/a/b" then appropriate requests get routed there. 
> I have run a "plain" cxf test by adapting the CXF provided "basic" jax-rs 
> test with the same resource classes, and it routes as I would expect. 
> I had intended to try and adapt the example in the aries jaxrs whiteboard 
> project, but I get test errors when I run an "mvn install",and it isn't 
> obvious to me how the jax-rs._example_-run/_example_.jar file mentioned in 
> the readme would get created.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1866) URI binding conflict resolution appears incorrect in jaxrs-whiteboard

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on ARIES-1866:


Commit 21ab76135c3a031ec19cdc59e5829bf72264bfb5 in aries-jax-rs-whiteboard's 
branch refs/heads/master from [~csierra]
[ https://gitbox.apache.org/repos/asf?p=aries-jax-rs-whiteboard.git;h=21ab761 ]

[ARIES-1866] Add comparator opt-in comparator

only kicks in if the service references specify a `service.ranking` property, 
otherwise let JAX-RS resolve the conflict.


> URI binding conflict resolution appears incorrect in jaxrs-whiteboard
> -
>
> Key: ARIES-1866
> URL: https://issues.apache.org/jira/browse/ARIES-1866
> Project: Aries
>  Issue Type: Bug
>  Components: jax-rs-whiteboard
> Environment: I'm using jax-rs whiteboard 1.0.1 on Windows, within 
> apache karaf.
>  
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: TestResource.java, TestResource2.java
>
>
> I'm seeing different behaviour in the URI resource binding conflict 
> resolution when using tje jax-rs whiteboard as then using "plain" cxf.
> Attached are two resource class implementations. One has a class level @Path 
> of "test", with then a subresource locator with an @Path of "\{a}" returning 
> another resource class that has a @GET with an @Path of "\{b}". 
> The other resource class has a class level @Path of "test/a/b". 
> Given a GET request for "/test/a/b" it should match the second of these 
> resource classes as being the most specific match. Instead it matches the 
> first. Indeed it seems that the presence of the first resource class stops 
> anything going to the second. If I change the @Path for the second resource 
> class to be "test2/a/b" then appropriate requests get routed there. 
> I have run a "plain" cxf test by adapting the CXF provided "basic" jax-rs 
> test with the same resource classes, and it routes as I would expect. 
> I had intended to try and adapt the example in the aries jaxrs whiteboard 
> project, but I get test errors when I run an "mvn install",and it isn't 
> obvious to me how the jax-rs._example_-run/_example_.jar file mentioned in 
> the readme would get created.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on ARIES-1867:


Commit 215e3821377ddfa22cc5682df47b1d334dd117e0 in aries-jax-rs-whiteboard's 
branch refs/heads/master from [~csierra]
[ https://gitbox.apache.org/repos/asf?p=aries-jax-rs-whiteboard.git;h=215e382 ]

[ARIES-1867] Add tests showing filter behaviour

regarding void returning methods. This tests show there might be a bug
when dealing with SSE subscribe methods because the
ContainerResponseFilter is not invoked.


> 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 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)

[jira] [Commented] (ARIES-1868) @Context injection points are re-injected per request even for singleton resource services

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on ARIES-1868:


Commit 6a553b4c96e26e007a2d4b77572f7617ac2146d6 in aries-jax-rs-whiteboard's 
branch refs/heads/master from [~csierra]
[ https://gitbox.apache.org/repos/asf?p=aries-jax-rs-whiteboard.git;h=6a553b4 ]

[ARIES-1868] Properly report if the service is singleton


> @Context injection points are re-injected per request even for singleton 
> resource services
> --
>
> Key: ARIES-1868
> URL: https://issues.apache.org/jira/browse/ARIES-1868
> Project: Aries
>  Issue Type: Bug
>  Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.2
>Reporter: Carlos Sierra
>Assignee: Carlos Sierra
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1866) URI binding conflict resolution appears incorrect in jaxrs-whiteboard

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on ARIES-1866:


Commit 71d88fe0153b3659f67bd8f558078421cf134dd9 in aries-jax-rs-whiteboard's 
branch refs/heads/master from [~csierra]
[ https://gitbox.apache.org/repos/asf?p=aries-jax-rs-whiteboard.git;h=71d88fe ]

[ARIES-1866] Add tests showing tie problem


> URI binding conflict resolution appears incorrect in jaxrs-whiteboard
> -
>
> Key: ARIES-1866
> URL: https://issues.apache.org/jira/browse/ARIES-1866
> Project: Aries
>  Issue Type: Bug
>  Components: jax-rs-whiteboard
> Environment: I'm using jax-rs whiteboard 1.0.1 on Windows, within 
> apache karaf.
>  
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: TestResource.java, TestResource2.java
>
>
> I'm seeing different behaviour in the URI resource binding conflict 
> resolution when using tje jax-rs whiteboard as then using "plain" cxf.
> Attached are two resource class implementations. One has a class level @Path 
> of "test", with then a subresource locator with an @Path of "\{a}" returning 
> another resource class that has a @GET with an @Path of "\{b}". 
> The other resource class has a class level @Path of "test/a/b". 
> Given a GET request for "/test/a/b" it should match the second of these 
> resource classes as being the most specific match. Instead it matches the 
> first. Indeed it seems that the presence of the first resource class stops 
> anything going to the second. If I change the @Path for the second resource 
> class to be "test2/a/b" then appropriate requests get routed there. 
> I have run a "plain" cxf test by adapting the CXF provided "basic" jax-rs 
> test with the same resource classes, and it routes as I would expect. 
> I had intended to try and adapt the example in the aries jaxrs whiteboard 
> project, but I get test errors when I run an "mvn install",and it isn't 
> obvious to me how the jax-rs._example_-run/_example_.jar file mentioned in 
> the readme would get created.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (ARIES-1711) Mapping files in persistence.xml not used

[Christian Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schneider reassigned ARIES-1711:
--

Assignee: Timothy Ward

> Mapping files in persistence.xml not used
> -
>
> Key: ARIES-1711
> URL: https://issues.apache.org/jira/browse/ARIES-1711
> Project: Aries
>  Issue Type: Bug
>  Components: JPA
>Affects Versions: jpa-2.7.0, jpa-2.6.1
> Environment: Apache Aries 2.6.1
> Hibernate 5.0.7.Final
> Felix 5.6.1
> JPA 2.1
>Reporter: Alexander Liepold
>Assignee: Timothy Ward
>Priority: Major
> Fix For: jpa-2.7.0
>
> Attachments: JPAHandler.patch, PersistenceUnit.patch, 
> aries-itest-mapping-files.zip
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The mapping files in a PeristenceUnit are not used by Apache Aries.
>  
> The same issue was noticed at this thread: 
> http://karaf.922171.n3.nabble.com/Aries-JPA-2-3-0-mapping-file-not-used-td4047501.html
> I have the same problem and I found out that the use of a mapping file in a 
> persistence.xml works only on particular circumstances.
> For example if I use the following declaration of a persistence.xml :
>  
> {code:xml}
> 
>version="2.1">
>  transaction-type="RESOURCE_LOCAL">
>   
> org.hibernate.jpa.HibernatePersistenceProvider
>   
> osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/testDB)
>   META-INF/developer-orm.xml
>   
>   META-INF/orm.xml
>   
>   test.Customer
>   ...
>   
>   ...
>   
>   
> 
> {code}
> On deployment of this persistence-unit the class {{test.Customer}} gets 
> bootstrapped from Hibernate. The mapping file {{META-INF/orm.xml}} is 
> detected automatically from the persistence provider.
> But the mapping file {{META-INF/developer-orm.xml}} is never detected.
>  
> If I fixed the particular code in the module Aries JPA Container locally. 
> After building and testing the Apache Aries Project I could deploy a 
> persistence.xml with multiple mapping files.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ARIES-1783) TransactionRequiredException when non-transactional method precedes a transactional one in the same service.

[Christian Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schneider resolved ARIES-1783.

   Resolution: Fixed
Fix Version/s: jpa-2.8.0

> TransactionRequiredException when non-transactional method precedes a 
> transactional one in the same service.
> 
>
> Key: ARIES-1783
> URL: https://issues.apache.org/jira/browse/ARIES-1783
> Project: Aries
>  Issue Type: Bug
>  Components: JPA
>Affects Versions: jpa-2.5.0
>Reporter: Daniel Estermann
>Assignee: Christian Schneider
>Priority: Major
> Fix For: jpa-2.8.0
>
>
> Assume I have a service implementation with a method annotated with 
> @Transactional and one of TxTypes not starting a transaction:
>  * NEVER
>  * NOT_SUPPORTED
>  * SUPPORTS
> From that non-transactional method I want to use a self-reference resolved 
> via BundleContext to call a transactional method in the same service, 
> annotated with one of those TxTypes:
>  * REQUIRED
>  * REQURES_NEW
> Since the resolved self-reference is a proxied object I expect it to be able 
> to start a new transaction. This is not the case however and the subject 
> exception occurs.
>  
> I created a test case revealing the issue in the following pull request: 
> https://github.com/apache/aries-jpa/pull/2



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1783) TransactionRequiredException when non-transactional method precedes a transactional one in the same service.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on ARIES-1783:


Commit 12292696477fd0b982fb8e8a82a11a87e9c15764 in aries-jpa's branch 
refs/heads/master from [~soundcrac...@gmail.com]
[ https://gitbox.apache.org/repos/asf?p=aries-jpa.git;h=1229269 ]

ARIES-1783 EM joins transaction when needed

EMSupplier makes a cached EM join a transaction if there is currently
an active one.

> TransactionRequiredException when non-transactional method precedes a 
> transactional one in the same service.
> 
>
> Key: ARIES-1783
> URL: https://issues.apache.org/jira/browse/ARIES-1783
> Project: Aries
>  Issue Type: Bug
>  Components: JPA
>Affects Versions: jpa-2.5.0
>Reporter: Daniel Estermann
>Assignee: Christian Schneider
>Priority: Major
>
> Assume I have a service implementation with a method annotated with 
> @Transactional and one of TxTypes not starting a transaction:
>  * NEVER
>  * NOT_SUPPORTED
>  * SUPPORTS
> From that non-transactional method I want to use a self-reference resolved 
> via BundleContext to call a transactional method in the same service, 
> annotated with one of those TxTypes:
>  * REQUIRED
>  * REQURES_NEW
> Since the resolved self-reference is a proxied object I expect it to be able 
> to start a new transaction. This is not the case however and the subject 
> exception occurs.
>  
> I created a test case revealing the issue in the following pull request: 
> https://github.com/apache/aries-jpa/pull/2



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1783) TransactionRequiredException when non-transactional method precedes a transactional one in the same service.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARIES-1783:
---

cschneider closed pull request #3: ARIES-1783 EM joins transaction when needed
URL: https://github.com/apache/aries-jpa/pull/3
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/itests/jpa-container-blueprint-testbundle/src/main/java/org/apache/aries/jpa/container/itest/bundle/blueprint/impl/CarServiceWithRequiresNew.java
 
b/itests/jpa-container-blueprint-testbundle/src/main/java/org/apache/aries/jpa/container/itest/bundle/blueprint/impl/CarServiceWithRequiresNew.java
index d1b041c..754bdd8 100644
--- 
a/itests/jpa-container-blueprint-testbundle/src/main/java/org/apache/aries/jpa/container/itest/bundle/blueprint/impl/CarServiceWithRequiresNew.java
+++ 
b/itests/jpa-container-blueprint-testbundle/src/main/java/org/apache/aries/jpa/container/itest/bundle/blueprint/impl/CarServiceWithRequiresNew.java
@@ -17,6 +17,7 @@
 
 import java.util.Arrays;
 import java.util.Collection;
+import java.util.List;
 
 import javax.transaction.Transactional;
 import javax.transaction.Transactional.TxType;
@@ -53,7 +54,9 @@ public void addCar(Car car) {
 ref = getService();
 CarService carService = bundleContext.getService(ref);
 carService.addCar(c);
-return Arrays.asList(this.getCar("TR123"));
+final List returnVal = Arrays.asList(this.getCar("TR123"));
+carService.deleteCar("TR123");
+return returnVal;
 } finally {
 if (ref != null) {
 bundleContext.ungetService(ref);
@@ -75,7 +78,9 @@ public void updateCar(Car car) {
 }
 
 @Override
+@Transactional
 public void deleteCar(String id) {
+em.remove(this.getCar(id));
 }
 
 public void setBundleContext(BundleContext bundleContext) {
diff --git 
a/itests/jpa-container-itest/src/test/java/org/apache/aries/jpa/blueprint/aries/itest/BlueprintTest.java
 
b/itests/jpa-container-itest/src/test/java/org/apache/aries/jpa/blueprint/aries/itest/BlueprintTest.java
index 507ff3e..ab516c4 100644
--- 
a/itests/jpa-container-itest/src/test/java/org/apache/aries/jpa/blueprint/aries/itest/BlueprintTest.java
+++ 
b/itests/jpa-container-itest/src/test/java/org/apache/aries/jpa/blueprint/aries/itest/BlueprintTest.java
@@ -43,10 +43,10 @@
 public class BlueprintTest extends AbstractCarJPAITest {
 @Inject
 Coordinator coordinator;
-
+
 @Inject
 UserTransaction ut;
-
+
 @Test
 public void testCoordination() {
 assertNoCoordination();
@@ -66,7 +66,7 @@ public void testCoordination() {
 Assert.assertEquals(0, carService.getCars().size());
 }
 }
-
+
 @Test
 public void testInjectToMethod() throws Exception {
 carLifecycle(getCarService("method"));
@@ -86,7 +86,7 @@ public void testEmf() throws Exception {
 public void testEm() throws Exception {
 carLifecycle(getCarService("em"));
 }
-
+
 @Test
 public void testEmJtaAnn() throws Exception {
 carLifecycle(getCarService("emJtaAnn"));
@@ -96,17 +96,17 @@ public void testEmJtaAnn() throws Exception {
 public void testSupplier() throws Exception {
 carLifecycle(getCarService("supplier"));
 }
-
+
 @Test
 public void testRealTransactional() throws Exception {
 carRealTransactionalLifecycle(getCarService("emJtaAnn"));
 }
-
+
 @Test
 public void testInlined() throws Exception {
 carRealTransactionalLifecycle(getCarService("emJtaAnnInlined"));
 }
-
+
 @Test
 public void testCoordinationLifecycle() throws InterruptedException, 
ExecutionException {
 CarService carService = getCarService("em");
@@ -127,7 +127,6 @@ public void testCoordinationLifecycle() throws 
InterruptedException, ExecutionEx
 }
 
 @Test
-@Ignore
 public void testCarWithRequiresNewAnnotation() throws Exception {
 CarService cs = getCarService("rn");
 cs.getCars();
@@ -146,7 +145,7 @@ private void carLifecycle(CarService carService) {
 assertBlueCar(carService.getCar(BLUE_PLATE));
 carService.deleteCar(BLUE_PLATE);
 }
-
+
 private void carRealTransactionalLifecycle(CarService carService) throws 
IllegalStateException, SystemException, NotSupportedException {
 assertNoCoordination();
 if (carService.getCar(BLACK_CAR_PLATE) != null) {
@@ -162,7 +161,7 @@ private void assertNoCoordination() {
 Coordination coord = coordinator.peek();
 Assert.assertNull("There should not be a coordination on 

[jira] [Commented] (ARIES-1783) TransactionRequiredException when non-transactional method precedes a transactional one in the same service.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on ARIES-1783:


Commit 56899eaaa94f29f576733784e2a51345a9733d09 in aries-jpa's branch 
refs/heads/master from [~ch...@die-schneider.net]
[ https://gitbox.apache.org/repos/asf?p=aries-jpa.git;h=56899ea ]

Merge pull request #3 from Smasherr/requires_new_after_never

ARIES-1783 EM joins transaction when needed

> TransactionRequiredException when non-transactional method precedes a 
> transactional one in the same service.
> 
>
> Key: ARIES-1783
> URL: https://issues.apache.org/jira/browse/ARIES-1783
> Project: Aries
>  Issue Type: Bug
>  Components: JPA
>Affects Versions: jpa-2.5.0
>Reporter: Daniel Estermann
>Assignee: Christian Schneider
>Priority: Major
>
> Assume I have a service implementation with a method annotated with 
> @Transactional and one of TxTypes not starting a transaction:
>  * NEVER
>  * NOT_SUPPORTED
>  * SUPPORTS
> From that non-transactional method I want to use a self-reference resolved 
> via BundleContext to call a transactional method in the same service, 
> annotated with one of those TxTypes:
>  * REQUIRED
>  * REQURES_NEW
> Since the resolved self-reference is a proxied object I expect it to be able 
> to start a new transaction. This is not the case however and the subject 
> exception occurs.
>  
> I created a test case revealing the issue in the following pull request: 
> https://github.com/apache/aries-jpa/pull/2



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (ARIES-1783) TransactionRequiredException when non-transactional method precedes a transactional one in the same service.

[Christian Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schneider reassigned ARIES-1783:
--

Assignee: Christian Schneider

> TransactionRequiredException when non-transactional method precedes a 
> transactional one in the same service.
> 
>
> Key: ARIES-1783
> URL: https://issues.apache.org/jira/browse/ARIES-1783
> Project: Aries
>  Issue Type: Bug
>  Components: JPA
>Affects Versions: jpa-2.5.0
>Reporter: Daniel Estermann
>Assignee: Christian Schneider
>Priority: Major
>
> Assume I have a service implementation with a method annotated with 
> @Transactional and one of TxTypes not starting a transaction:
>  * NEVER
>  * NOT_SUPPORTED
>  * SUPPORTS
> From that non-transactional method I want to use a self-reference resolved 
> via BundleContext to call a transactional method in the same service, 
> annotated with one of those TxTypes:
>  * REQUIRED
>  * REQURES_NEW
> Since the resolved self-reference is a proxied object I expect it to be able 
> to start a new transaction. This is not the case however and the subject 
> exception occurs.
>  
> I created a test case revealing the issue in the following pull request: 
> https://github.com/apache/aries-jpa/pull/2



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARIES-1783) TransactionRequiredException when non-transactional method precedes a transactional one in the same service.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARIES-1783:
---

Smasherr opened a new pull request #3: ARIES-1783 EM joins transaction when 
needed
URL: https://github.com/apache/aries-jpa/pull/3
 
 
   EMSupplier makes a cached EM join a transaction if there is currently
   an active one.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> TransactionRequiredException when non-transactional method precedes a 
> transactional one in the same service.
> 
>
> Key: ARIES-1783
> URL: https://issues.apache.org/jira/browse/ARIES-1783
> Project: Aries
>  Issue Type: Bug
>  Components: JPA
>Affects Versions: jpa-2.5.0
>Reporter: Daniel Estermann
>Priority: Major
>
> Assume I have a service implementation with a method annotated with 
> @Transactional and one of TxTypes not starting a transaction:
>  * NEVER
>  * NOT_SUPPORTED
>  * SUPPORTS
> From that non-transactional method I want to use a self-reference resolved 
> via BundleContext to call a transactional method in the same service, 
> annotated with one of those TxTypes:
>  * REQUIRED
>  * REQURES_NEW
> Since the resolved self-reference is a proxied object I expect it to be able 
> to start a new transaction. This is not the case however and the subject 
> exception occurs.
>  
> I created a test case revealing the issue in the following pull request: 
> https://github.com/apache/aries-jpa/pull/2



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[Carlos Sierra (JIRA)]

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

Carlos Sierra commented on ARIES-1867:
--

hey [~tomq42],

in a short time I will push my test to upstream. It shows that, as well as CXF, 
the whiteboard is *also* invoking the filter for a void returning resource. On 
the other hand it also shows that, either the whiteboard or CXF, is not 
invoking the filter for the {{subscribe}} method. I would say the problem is on 
CXF code because, as you said, most of that logic resides on CXF.

Maybe we can elaborate a bit more on top of the tests to find the discrepancies 
we are seeing.

Carlos.

> 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 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)

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

[Tom Quarendon (JIRA)]

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

Tom Quarendon commented on ARIES-1867:
--

[~csierra], Although I didn't create an SSE example in cxf, I did create a 
simpler example not involving SSE where CXF was correctly invoking the filter. 
With the same kind of example within the aries jaxrs whiteboard, the filter was 
not invoked.

I've been looking around the jaxrs whiteboard code, but haven't been able to 
understand any of it yet. I'm surprised that it's involved in any of this kind 
of logic, I would have expected the binding of URIs to resource methods and 
filters to be purely within the CXF code.

> 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 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)

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

[Carlos Sierra (JIRA)]

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

Carlos Sierra commented on ARIES-1867:
--

hey [~tomq42],

I have created a test (not in upstream yet) that shows that the whiteboard is 
properly registering a filter for a resource method returning void.

I have also confirmed that the ContainerRequestFilter is, indeed, not invoked 
for the usual {{subscribe}} method in the SSE resources. I believe it is CXF 
3.2.5 which is causing this but I need to confirm on CXF codebase.

> 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 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)

[jira] [Created] (ARIES-1868) @Context injection points are re-injected per request even for singleton resource services

[Carlos Sierra (JIRA)]

Carlos Sierra created ARIES-1868:


 Summary: @Context injection points are re-injected per request 
even for singleton resource services
 Key: ARIES-1868
 URL: https://issues.apache.org/jira/browse/ARIES-1868
 Project: Aries
  Issue Type: Bug
  Components: jax-rs-whiteboard
Affects Versions: jax-rs-whiteboard-1.0.2
Reporter: Carlos Sierra
Assignee: Carlos Sierra






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[Tom Quarendon (JIRA)]

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

Tom Quarendon edited comment on ARIES-1867 at 11/26/18 10:28 AM:
-

I'm already using the snapshot. Without it I would get a NPE whenever I called 
resource methods that returned void. The snapshot fixed that issue, but this 
issue remains.

 

 


was (Author: tomq42):
I'm already using the snapshot. Without it I would get a NPE whenever I called 
resource methods that returned null. The snapshot fixed that issue, but this 
issue remains.

 

 

> 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 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)

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

[Carlos Sierra (JIRA)]

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

Carlos Sierra commented on ARIES-1867:
--

Thx... I have removed the link

> 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 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)

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

[Carlos Sierra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carlos Sierra updated ARIES-1867:
-
Affects Version/s: jax-rs-whiteboard-1.0.2

> 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 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)

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

[Tom Quarendon (JIRA)]

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

Tom Quarendon commented on ARIES-1867:
--

I'm already using the snapshot. Without it I would get a NPE whenever I called 
resource methods that returned null. The snapshot fixed that issue, but this 
issue remains.

 

 

> 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
>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 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)

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

[Carlos Sierra (JIRA)]

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

Carlos Sierra commented on ARIES-1867:
--

Hi Tom,

thank you very much for your report. I believe this issue is related to 
ARIES-1852. Could you please verify if the latest snapshot that includes a fix 
works for you?

Thx.

Carlos.

> 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
>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 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)

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

[Carlos Sierra (JIRA)]

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

Carlos Sierra edited comment on ARIES-1867 at 11/26/18 9:09 AM:


Hi [~tomq42],

thank you very much for your report. I believe this issue is related to 
ARIES-1852. Could you please verify if the latest snapshot that includes a fix 
works for you?

Thx.

Carlos.


was (Author: csierra):
Hi Tom,

thank you very much for your report. I believe this issue is related to 
ARIES-1852. Could you please verify if the latest snapshot that includes a fix 
works for you?

Thx.

Carlos.

> 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
>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 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)

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

[Carlos Sierra (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carlos Sierra reassigned ARIES-1867:


Assignee: Carlos Sierra

> 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
>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 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)

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

[Tom Quarendon (JIRA)]

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

Tom Quarendon commented on ARIES-1867:
--

This is a block issue for us. I can't proceed i adopting jaxrs-whiteboard 
without a fix for this.

> 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
>Reporter: Tom Quarendon
>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 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)

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

[Tom Quarendon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tom Quarendon updated ARIES-1867:
-
Priority: Blocker  (was: Major)

> 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
>Reporter: Tom Quarendon
>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 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)

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

[Tom Quarendon (JIRA)]

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

Tom Quarendon commented on ARIES-1867:
--

Attached are my three source files (Server.java, TestService3.java and 
CORSFilter.java) for my plain cxf test.

> 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
>Reporter: Tom Quarendon
>Priority: Major
> 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 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)

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

[Tom Quarendon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tom Quarendon updated ARIES-1867:
-
Attachment: CORSFilter.java

> 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
>Reporter: Tom Quarendon
>Priority: Major
> 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 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)

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

[Tom Quarendon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tom Quarendon updated ARIES-1867:
-
Attachment: Server.java

> 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
>Reporter: Tom Quarendon
>Priority: Major
> 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 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)

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

[Tom Quarendon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tom Quarendon updated ARIES-1867:
-
Attachment: TestService3.java

> 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
>Reporter: Tom Quarendon
>Priority: Major
> 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 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)

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

[Tom Quarendon (JIRA)]

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

Tom Quarendon commented on ARIES-1867:
--

This appears to be a bug in the aries jaxrs whiteboard. I have created a plain 
CXF example where a ContainerResponseFilter is matched to a resource method 
returning void.

Not knowing CXF I can't make any sense out of the jaxrs whiteboard code, so 
I've no idea where this kind of logic might reside.

> 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
>Reporter: Tom Quarendon
>Priority: Major
>
> 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 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)

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

[Tom Quarendon (JIRA)]

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

Tom Quarendon commented on ARIES-1867:
--

I have other cases where the CORS filter isn't being bound. It appears to be 
that if the resource method has a void return type that the CORS filter 
(ContainerResponseFilter) isn't processed in the chain, so the response doesn't 
include the required CORS headers.

I'll create a plain CXF example and see if that also has the same behaviour.

> 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
>Reporter: Tom Quarendon
>Priority: Major
>
> 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 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)