[jira] [Created] (CXF-6257) Creating and Endpoint using JAX-WS API, getting the binding and then publishing causes a NullPointerException
Carlos Sierra created CXF-6257:
--
Summary: Creating and Endpoint using JAX-WS API, getting the
binding and then publishing causes a NullPointerException
Key: CXF-6257
URL: https://issues.apache.org/jira/browse/CXF-6257
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Affects Versions: 3.0.3
Environment: jdk.1.7.0_45
Reporter: Carlos Sierra
The following code will trigger a NullPointerException
---
Endpoint endpoint = Endpoint.create(new Calculator());
Binding binding = endpoint.getBinding();
endpoint.publish("http://localhost:9494/calculator";);
---
This same code using JDK's JAX-WS implementation works without problems.
Requesting the binding at that point, maybe to register handlers, causes a call
to getServer(null) which ends up setting a null address:
Info: Setting the server's publish address to be null
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6257) Creating and Endpoint using JAX-WS API, getting the binding and then publishing causes a NullPointerException
[
https://issues.apache.org/jira/browse/CXF-6257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14334801#comment-14334801
]
Carlos Sierra commented on CXF-6257:
I will try to provide a maven project with the example
bests
> Creating and Endpoint using JAX-WS API, getting the binding and then
> publishing causes a NullPointerException
> -
>
> Key: CXF-6257
> URL: https://issues.apache.org/jira/browse/CXF-6257
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.3
> Environment: jdk.1.7.0_45
>Reporter: Carlos Sierra
>
> The following code will trigger a NullPointerException
> ---
> Endpoint endpoint = Endpoint.create(new Calculator());
> Binding binding = endpoint.getBinding();
> endpoint.publish("http://localhost:9494/calculator";);
> ---
> This same code using JDK's JAX-WS implementation works without problems.
> Requesting the binding at that point, maybe to register handlers, causes a
> call to getServer(null) which ends up setting a null address:
> Info: Setting the server's publish address to be null
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6257) Creating and Endpoint using JAX-WS API, getting the binding and then publishing causes a NullPointerException
[
https://issues.apache.org/jira/browse/CXF-6257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra updated CXF-6257:
---
Attachment: cxf6257.zip
Maven project showing the bug
> Creating and Endpoint using JAX-WS API, getting the binding and then
> publishing causes a NullPointerException
> -
>
> Key: CXF-6257
> URL: https://issues.apache.org/jira/browse/CXF-6257
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.3
> Environment: jdk.1.7.0_45
>Reporter: Carlos Sierra
> Attachments: cxf6257.zip
>
>
> The following code will trigger a NullPointerException
> ---
> Endpoint endpoint = Endpoint.create(new Calculator());
> Binding binding = endpoint.getBinding();
> endpoint.publish("http://localhost:9494/calculator";);
> ---
> This same code using JDK's JAX-WS implementation works without problems.
> Requesting the binding at that point, maybe to register handlers, causes a
> call to getServer(null) which ends up setting a null address:
> Info: Setting the server's publish address to be null
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6257) Creating and Endpoint using JAX-WS API, getting the binding and then publishing causes a NullPointerException
[
https://issues.apache.org/jira/browse/CXF-6257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14336345#comment-14336345
]
Carlos Sierra commented on CXF-6257:
I have attached a maven project showing the problem. It happens using
CXFNonSpringServlet. It does not seem to happen using
cxf-rt-transports-http-jetty.
> Creating and Endpoint using JAX-WS API, getting the binding and then
> publishing causes a NullPointerException
> -
>
> Key: CXF-6257
> URL: https://issues.apache.org/jira/browse/CXF-6257
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.3
> Environment: jdk.1.7.0_45
>Reporter: Carlos Sierra
> Attachments: cxf6257.zip
>
>
> The following code will trigger a NullPointerException
> ---
> Endpoint endpoint = Endpoint.create(new Calculator());
> Binding binding = endpoint.getBinding();
> endpoint.publish("http://localhost:9494/calculator";);
> ---
> This same code using JDK's JAX-WS implementation works without problems.
> Requesting the binding at that point, maybe to register handlers, causes a
> call to getServer(null) which ends up setting a null address:
> Info: Setting the server's publish address to be null
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6257) Creating and Endpoint using JAX-WS API, getting the binding and then publishing causes a NullPointerException
[
https://issues.apache.org/jira/browse/CXF-6257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14383480#comment-14383480
]
Carlos Sierra commented on CXF-6257:
It was the least I could do.
Thx you guys for all your great work.
> Creating and Endpoint using JAX-WS API, getting the binding and then
> publishing causes a NullPointerException
> -
>
> Key: CXF-6257
> URL: https://issues.apache.org/jira/browse/CXF-6257
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.0.3
> Environment: jdk.1.7.0_45
>Reporter: Carlos Sierra
>Assignee: Akitoshi Yoshida
> Fix For: 3.1.0, 2.7.16, 3.0.5
>
> Attachments: cxf6257.zip
>
>
> The following code will trigger a NullPointerException
> ---
> Endpoint endpoint = Endpoint.create(new Calculator());
> Binding binding = endpoint.getBinding();
> endpoint.publish("http://localhost:9494/calculator";);
> ---
> This same code using JDK's JAX-WS implementation works without problems.
> Requesting the binding at that point, maybe to register handlers, causes a
> call to getServer(null) which ends up setting a null address:
> Info: Setting the server's publish address to be null
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7409) ServiceConstructionException when adding JAX-RS application ruins existing applications
Carlos Sierra created CXF-7409:
--
Summary: ServiceConstructionException when adding JAX-RS
application ruins existing applications
Key: CXF-7409
URL: https://issues.apache.org/jira/browse/CXF-7409
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.1.10
Reporter: Carlos Sierra
if a new application conflicts with
an existing one, an Exception:
---
Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
There is an endpoint already running on /test-application.
at
org.apache.cxf.jaxrs.JAXRSBindingFactory.addListener(JAXRSBindingFactory.java:86)
at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:123)
at
org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:206)
---
is raised, which is expected. The problem is that the already existing
application ceases to work in the bus.
Following [~sergeyb]'s advice I tried removing
{code:java}
server.destroy()
{code}
from the
{code:java}
catch(RuntimeException e) {}
{code}
block in JAXRSServerFactoryBean's create method. However there is a comment
saying that that invocation is there to prevent leaks. Also, invocations to
server.destroy() in other moments don't affect other existing applications in
the bus.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CXF-7410) ServiceConstructionException when adding JAX-RS application ruins existing applications
Carlos Sierra created CXF-7410:
--
Summary: ServiceConstructionException when adding JAX-RS
application ruins existing applications
Key: CXF-7410
URL: https://issues.apache.org/jira/browse/CXF-7410
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.1.10
Reporter: Carlos Sierra
if a new application conflicts with
an existing one, an Exception:
---
Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
There is an endpoint already running on /test-application.
at
org.apache.cxf.jaxrs.JAXRSBindingFactory.addListener(JAXRSBindingFactory.java:86)
at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:123)
at
org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:206)
---
is raised, which is expected. The problem is that the already existing
application ceases to work in the bus.
Following [~sergeyb]'s advice I tried removing
{code:java}
server.destroy()
{code}
from the
{code:java}
catch(RuntimeException e) {}
{code}
block in JAXRSServerFactoryBean's create method. However there is a comment
saying that that invocation is there to prevent leaks. Also, invocations to
server.destroy() in other moments don't affect other existing applications in
the bus.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (CXF-7410) ServiceConstructionException when adding JAX-RS application ruins existing applications
[
https://issues.apache.org/jira/browse/CXF-7410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra closed CXF-7410.
--
Resolution: Duplicate
> ServiceConstructionException when adding JAX-RS application ruins existing
> applications
> ---
>
> Key: CXF-7410
> URL: https://issues.apache.org/jira/browse/CXF-7410
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10
>Reporter: Carlos Sierra
>
> if a new application conflicts with
> an existing one, an Exception:
> ---
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
> There is an endpoint already running on /test-application.
> at
> org.apache.cxf.jaxrs.JAXRSBindingFactory.addListener(JAXRSBindingFactory.java:86)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:123)
> at
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:206)
> ---
> is raised, which is expected. The problem is that the already existing
> application ceases to work in the bus.
> Following [~sergeyb]'s advice I tried removing
> {code:java}
> server.destroy()
> {code}
> from the
> {code:java}
> catch(RuntimeException e) {}
> {code}
> block in JAXRSServerFactoryBean's create method. However there is a comment
> saying that that invocation is there to prevent leaks. Also, invocations to
> server.destroy() in other moments don't affect other existing applications in
> the bus.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7409) ServiceConstructionException when adding JAX-RS application ruins existing applications
[
https://issues.apache.org/jira/browse/CXF-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050301#comment-16050301
]
Carlos Sierra commented on CXF-7409:
On an deeper issue it looks like the culprit is the
{code:java}
getDestination().shutdown();
{code}
it seems that the destination is shared between the server that have the same
endpoint address.
> ServiceConstructionException when adding JAX-RS application ruins existing
> applications
> ---
>
> Key: CXF-7409
> URL: https://issues.apache.org/jira/browse/CXF-7409
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10
>Reporter: Carlos Sierra
>
> if a new application conflicts with
> an existing one, an Exception:
> ---
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
> There is an endpoint already running on /test-application.
> at
> org.apache.cxf.jaxrs.JAXRSBindingFactory.addListener(JAXRSBindingFactory.java:86)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:123)
> at
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:206)
> ---
> is raised, which is expected. The problem is that the already existing
> application ceases to work in the bus.
> Following [~sergeyb]'s advice I tried removing
> {code:java}
> server.destroy()
> {code}
> from the
> {code:java}
> catch(RuntimeException e) {}
> {code}
> block in JAXRSServerFactoryBean's create method. However there is a comment
> saying that that invocation is there to prevent leaks. Also, invocations to
> server.destroy() in other moments don't affect other existing applications in
> the bus.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7409) ServiceConstructionException when adding JAX-RS application ruins existing applications
[
https://issues.apache.org/jira/browse/CXF-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119758#comment-16119758
]
Carlos Sierra commented on CXF-7409:
hey [~sergeyb],
thanks for looking into this. I have rechecked and this is still happening in
our case, even in 3.1.12.
I have looked at JAXRSClientServerBookTest and we are bootstrapping CXF using
CXFNonSpringServlet:
{code:java}
CXFNonSpringServlet cxfNonSpringServlet = new CXFNonSpringServlet();
cxfNonSpringServlet.setBus(_bus);
{code}
I can see in your test that it is using SpringBusFactory. Could that be
responsible for the different behavior?
I know that this might not be orthodox but I could point you to a branch in our
project with the failing test and the way we worked it around. Would that be
useful for you? I can see in my debug that the culprit is:
{code:java}
getDestination().shutdown()
{code}
because the same destination is shared between all the servers that are created
for the same address, thus effectively destroying the destination when the
second and conflicting server is created.
> ServiceConstructionException when adding JAX-RS application ruins existing
> applications
> ---
>
> Key: CXF-7409
> URL: https://issues.apache.org/jira/browse/CXF-7409
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10
>Reporter: Carlos Sierra
>
> if a new application conflicts with
> an existing one, an Exception:
> ---
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
> There is an endpoint already running on /test-application.
> at
> org.apache.cxf.jaxrs.JAXRSBindingFactory.addListener(JAXRSBindingFactory.java:86)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:123)
> at
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:206)
> ---
> is raised, which is expected. The problem is that the already existing
> application ceases to work in the bus.
> Following [~sergeyb]'s advice I tried removing
> {code:java}
> server.destroy()
> {code}
> from the
> {code:java}
> catch(RuntimeException e) {}
> {code}
> block in JAXRSServerFactoryBean's create method. However there is a comment
> saying that that invocation is there to prevent leaks. Also, invocations to
> server.destroy() in other moments don't affect other existing applications in
> the bus.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CXF-7409) ServiceConstructionException when adding JAX-RS application ruins existing applications
[
https://issues.apache.org/jira/browse/CXF-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119758#comment-16119758
]
Carlos Sierra edited comment on CXF-7409 at 8/9/17 11:52 AM:
-
hey [~sergeyb],
thanks for looking into this. I have rechecked and this is still happening in
our case, even in 3.1.12.
I have looked at JAXRSClientServerBookTest and we are bootstrapping CXF using
CXFNonSpringServlet:
{code:java}
CXFNonSpringServlet cxfNonSpringServlet = new CXFNonSpringServlet();
cxfNonSpringServlet.setBus(_bus);
{code}
I can see in your test that it is using SpringBusFactory. Could that be
responsible for the different behavior?
I know that this might not be orthodox but I could point you to a branch in our
project with the failing test and the way we worked it around. Would that be
useful for you? I can see in my debug that the culprit is:
{code:java}
getDestination().shutdown()
{code}
because the same destination is shared between all the servers that are created
for the same address, thus effectively destroying the destination when the
second and conflicting server is shutdown.
was (Author: csierra):
hey [~sergeyb],
thanks for looking into this. I have rechecked and this is still happening in
our case, even in 3.1.12.
I have looked at JAXRSClientServerBookTest and we are bootstrapping CXF using
CXFNonSpringServlet:
{code:java}
CXFNonSpringServlet cxfNonSpringServlet = new CXFNonSpringServlet();
cxfNonSpringServlet.setBus(_bus);
{code}
I can see in your test that it is using SpringBusFactory. Could that be
responsible for the different behavior?
I know that this might not be orthodox but I could point you to a branch in our
project with the failing test and the way we worked it around. Would that be
useful for you? I can see in my debug that the culprit is:
{code:java}
getDestination().shutdown()
{code}
because the same destination is shared between all the servers that are created
for the same address, thus effectively destroying the destination when the
second and conflicting server is created.
> ServiceConstructionException when adding JAX-RS application ruins existing
> applications
> ---
>
> Key: CXF-7409
> URL: https://issues.apache.org/jira/browse/CXF-7409
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10
>Reporter: Carlos Sierra
>
> if a new application conflicts with
> an existing one, an Exception:
> ---
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
> There is an endpoint already running on /test-application.
> at
> org.apache.cxf.jaxrs.JAXRSBindingFactory.addListener(JAXRSBindingFactory.java:86)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:123)
> at
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:206)
> ---
> is raised, which is expected. The problem is that the already existing
> application ceases to work in the bus.
> Following [~sergeyb]'s advice I tried removing
> {code:java}
> server.destroy()
> {code}
> from the
> {code:java}
> catch(RuntimeException e) {}
> {code}
> block in JAXRSServerFactoryBean's create method. However there is a comment
> saying that that invocation is there to prevent leaks. Also, invocations to
> server.destroy() in other moments don't affect other existing applications in
> the bus.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CXF-7409) ServiceConstructionException when adding JAX-RS application ruins existing applications
[
https://issues.apache.org/jira/browse/CXF-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119789#comment-16119789
]
Carlos Sierra edited comment on CXF-7409 at 8/9/17 12:17 PM:
-
you mean the ApplicationPath annotation?
we are not using it in this case, we are setting the address in:
{code}
jaxRsServerFactoryBean.setAddress(address);
{code}
was (Author: csierra):
you mean the ApplicationPath annotation?
we are not using in this case, we are setting the address in:
{code}
jaxRsServerFactoryBean.setAddress(address);
{code}
> ServiceConstructionException when adding JAX-RS application ruins existing
> applications
> ---
>
> Key: CXF-7409
> URL: https://issues.apache.org/jira/browse/CXF-7409
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10
>Reporter: Carlos Sierra
>
> if a new application conflicts with
> an existing one, an Exception:
> ---
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
> There is an endpoint already running on /test-application.
> at
> org.apache.cxf.jaxrs.JAXRSBindingFactory.addListener(JAXRSBindingFactory.java:86)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:123)
> at
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:206)
> ---
> is raised, which is expected. The problem is that the already existing
> application ceases to work in the bus.
> Following [~sergeyb]'s advice I tried removing
> {code:java}
> server.destroy()
> {code}
> from the
> {code:java}
> catch(RuntimeException e) {}
> {code}
> block in JAXRSServerFactoryBean's create method. However there is a comment
> saying that that invocation is there to prevent leaks. Also, invocations to
> server.destroy() in other moments don't affect other existing applications in
> the bus.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7409) ServiceConstructionException when adding JAX-RS application ruins existing applications
[
https://issues.apache.org/jira/browse/CXF-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119789#comment-16119789
]
Carlos Sierra commented on CXF-7409:
you mean the ApplicationPath annotation?
we are not using in this case, we are setting the address in:
{code}
jaxRsServerFactoryBean.setAddress(address);
{code}
> ServiceConstructionException when adding JAX-RS application ruins existing
> applications
> ---
>
> Key: CXF-7409
> URL: https://issues.apache.org/jira/browse/CXF-7409
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10
>Reporter: Carlos Sierra
>
> if a new application conflicts with
> an existing one, an Exception:
> ---
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
> There is an endpoint already running on /test-application.
> at
> org.apache.cxf.jaxrs.JAXRSBindingFactory.addListener(JAXRSBindingFactory.java:86)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:123)
> at
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:206)
> ---
> is raised, which is expected. The problem is that the already existing
> application ceases to work in the bus.
> Following [~sergeyb]'s advice I tried removing
> {code:java}
> server.destroy()
> {code}
> from the
> {code:java}
> catch(RuntimeException e) {}
> {code}
> block in JAXRSServerFactoryBean's create method. However there is a comment
> saying that that invocation is there to prevent leaks. Also, invocations to
> server.destroy() in other moments don't affect other existing applications in
> the bus.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CXF-7409) ServiceConstructionException when adding JAX-RS application ruins existing applications
[
https://issues.apache.org/jira/browse/CXF-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120053#comment-16120053
]
Carlos Sierra commented on CXF-7409:
In our case this address is coming from a property on a OSGi service reference.
We are avoiding it at the moment using a custom destination Factory to detect
the conflict before it gets to destroy the server.
To be honest I did not think having several applications per servlet would be a
problem. Would you suggest we spawn a servlet for each of the applications? If
you think CXF does not support other way I will refactor and make sure there is
only one application per servlet (if no other considerations apply)
I will try and find some time to create a test for you. I need to get
acquainted with your tree. But with you comments I guess you encouraged me to
change our implementation and completely work around this problem from the
root.
> ServiceConstructionException when adding JAX-RS application ruins existing
> applications
> ---
>
> Key: CXF-7409
> URL: https://issues.apache.org/jira/browse/CXF-7409
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.10
>Reporter: Carlos Sierra
>
> if a new application conflicts with
> an existing one, an Exception:
> ---
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException:
> There is an endpoint already running on /test-application.
> at
> org.apache.cxf.jaxrs.JAXRSBindingFactory.addListener(JAXRSBindingFactory.java:86)
> at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:123)
> at
> org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:206)
> ---
> is raised, which is expected. The problem is that the already existing
> application ceases to work in the bus.
> Following [~sergeyb]'s advice I tried removing
> {code:java}
> server.destroy()
> {code}
> from the
> {code:java}
> catch(RuntimeException e) {}
> {code}
> block in JAXRSServerFactoryBean's create method. However there is a comment
> saying that that invocation is there to prevent leaks. Also, invocations to
> server.destroy() in other moments don't affect other existing applications in
> the bus.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CXF-7549) Can't register Feature from inside another Feature in JAX-RS
Carlos Sierra created CXF-7549: -- Summary: Can't register Feature from inside another Feature in JAX-RS Key: CXF-7549 URL: https://issues.apache.org/jira/browse/CXF-7549 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.2.1, 3.2.0 Reporter: Carlos Sierra Registering a Feature from within a Feature lead to ServiceConstruction exception. It is explicitly stated in the spec that it must be possible to register a feature inside another feature. In CXF this leads to a ServiceContruction exception caused by a NullPointerException. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7549) Can't register Feature from inside another Feature in JAX-RS
[ https://issues.apache.org/jira/browse/CXF-7549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241934#comment-16241934 ] Carlos Sierra commented on CXF-7549: Test uploaded to https://github.com/apache/cxf/pull/334 > Can't register Feature from inside another Feature in JAX-RS > > > Key: CXF-7549 > URL: https://issues.apache.org/jira/browse/CXF-7549 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.2.0, 3.2.1 >Reporter: Carlos Sierra > > Registering a Feature from within a Feature lead to ServiceConstruction > exception. > It is explicitly stated in the spec that it must be possible to register a > feature inside another feature. In CXF this leads to a ServiceContruction > exception caused by a NullPointerException. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CXF-7549) Can't register Feature from inside another Feature in JAX-RS
[ https://issues.apache.org/jira/browse/CXF-7549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242517#comment-16242517 ] Carlos Sierra commented on CXF-7549: Wow!... that was fast. Thanks to you! > Can't register Feature from inside another Feature in JAX-RS > > > Key: CXF-7549 > URL: https://issues.apache.org/jira/browse/CXF-7549 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.2.0, 3.2.1 >Reporter: Carlos Sierra >Assignee: Sergey Beryozkin > Fix For: 3.1.15, 3.2.2 > > > Registering a Feature from within a Feature lead to ServiceConstruction > exception. > It is explicitly stated in the spec that it must be possible to register a > feature inside another feature. In CXF this leads to a ServiceContruction > exception caused by a NullPointerException. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CXF-7614) DynamicFeature is not invoked for sub resources
Carlos Sierra created CXF-7614:
--
Summary: DynamicFeature is not invoked for sub resources
Key: CXF-7614
URL: https://issues.apache.org/jira/browse/CXF-7614
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.2.2
Reporter: Carlos Sierra
According to the javadoc of DynamicFeature the callback method is to be invoked
for relevant methods in resource or sub-resources. In the current
implementation methods on sub-resource are NOT being invoked.
{code:java}
public class ResourceWithSubResource {
@Path("/resource1")
public SubResource getResource() {
return new SubResource("Resource1: ");
}
}{code}
{code:java}
public class SubResource {
public SubResource(String param) {
_param = param;
}
@GET
public String getParam() {
return "Returning: " + _param;
}
@Path("/{path}")
public SubResource subPath(@PathParam("path") String subPath) {
return new SubResource(_param + "-" + subPath);
}
private String _param;
}
{code}
in the provided example a _DynamicFeature_ is only invoked for _getResource()_
and it should also be invoked for relevant methods in _SubResource_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CXF-7614) DynamicFeature is not invoked for sub resources
[
https://issues.apache.org/jira/browse/CXF-7614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra closed CXF-7614.
--
Resolution: Not A Bug
> DynamicFeature is not invoked for sub resources
> ---
>
> Key: CXF-7614
> URL: https://issues.apache.org/jira/browse/CXF-7614
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Carlos Sierra
>Priority: Major
>
> According to the javadoc of DynamicFeature the callback method is to be
> invoked for relevant methods in resource or sub-resources. In the current
> implementation methods on sub-resource are NOT being invoked.
> {code:java}
> public class ResourceWithSubResource {
> @Path("/resource1")
> public SubResource getResource() {
> return new SubResource("Resource1: ");
> }
> }{code}
> {code:java}
> public class SubResource {
> public SubResource(String param) {
> _param = param;
> }
> @GET
> public String getParam() {
> return "Returning: " + _param;
> }
> @Path("/{path}")
> public SubResource subPath(@PathParam("path") String subPath) {
> return new SubResource(_param + "-" + subPath);
> }
> private String _param;
> }
> {code}
> in the provided example a _DynamicFeature_ is only invoked for
> _getResource()_ and it should also be invoked for relevant methods in
> _SubResource_.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7614) DynamicFeature is not invoked for sub resources
[
https://issues.apache.org/jira/browse/CXF-7614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16328866#comment-16328866
]
Carlos Sierra commented on CXF-7614:
it looks like it is configurable with
_getServiceFactory().setEnableStaticResolution(true)_
> DynamicFeature is not invoked for sub resources
> ---
>
> Key: CXF-7614
> URL: https://issues.apache.org/jira/browse/CXF-7614
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Carlos Sierra
>Priority: Major
>
> According to the javadoc of DynamicFeature the callback method is to be
> invoked for relevant methods in resource or sub-resources. In the current
> implementation methods on sub-resource are NOT being invoked.
> {code:java}
> public class ResourceWithSubResource {
> @Path("/resource1")
> public SubResource getResource() {
> return new SubResource("Resource1: ");
> }
> }{code}
> {code:java}
> public class SubResource {
> public SubResource(String param) {
> _param = param;
> }
> @GET
> public String getParam() {
> return "Returning: " + _param;
> }
> @Path("/{path}")
> public SubResource subPath(@PathParam("path") String subPath) {
> return new SubResource(_param + "-" + subPath);
> }
> private String _param;
> }
> {code}
> in the provided example a _DynamicFeature_ is only invoked for
> _getResource()_ and it should also be invoked for relevant methods in
> _SubResource_.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (CXF-7614) DynamicFeature is not invoked for sub resources
[
https://issues.apache.org/jira/browse/CXF-7614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra reopened CXF-7614:
ok... so it looks like if _staticResolution_ is set to true then _sub resource
locators_ that return _Object_ are no longer resolved at runtime.
It looks like this behaviour should not be governed by the same flag. Shouldn't
this be resolved statically if the information is present in types when
DynamicFeatures are invoked? If there is no information that's fine, but the
invokation of the DynamicFeature should not affect the later resolution in the
runtime, should it?
I would expect the runtime to always invoke DynamicFeature with sub resource
information whenever that information is available and then try to resolve the
sub resources in request time as dynamically as possible.
> DynamicFeature is not invoked for sub resources
> ---
>
> Key: CXF-7614
> URL: https://issues.apache.org/jira/browse/CXF-7614
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Carlos Sierra
>Priority: Major
>
> According to the javadoc of DynamicFeature the callback method is to be
> invoked for relevant methods in resource or sub-resources. In the current
> implementation methods on sub-resource are NOT being invoked.
> {code:java}
> public class ResourceWithSubResource {
> @Path("/resource1")
> public SubResource getResource() {
> return new SubResource("Resource1: ");
> }
> }{code}
> {code:java}
> public class SubResource {
> public SubResource(String param) {
> _param = param;
> }
> @GET
> public String getParam() {
> return "Returning: " + _param;
> }
> @Path("/{path}")
> public SubResource subPath(@PathParam("path") String subPath) {
> return new SubResource(_param + "-" + subPath);
> }
> private String _param;
> }
> {code}
> in the provided example a _DynamicFeature_ is only invoked for
> _getResource()_ and it should also be invoked for relevant methods in
> _SubResource_.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7614) DynamicFeature is not invoked for sub resources
[
https://issues.apache.org/jira/browse/CXF-7614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16329039#comment-16329039
]
Carlos Sierra commented on CXF-7614:
hey,
not really... I would suggest that the DynamicFeature should always be executed
as if staticResolution was set to _true_ and during the request the
_sub-resources_ should be resolved like if _staticResolution_ was set to
_false_. This way the _DynamicFeature_ would be invoked with as much
information as it is available without compromising the ability of the runtime
to resolve the _sub-resources_ as dynamically as possible.
Do you think this would make sense?
> DynamicFeature is not invoked for sub resources
> ---
>
> Key: CXF-7614
> URL: https://issues.apache.org/jira/browse/CXF-7614
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Carlos Sierra
>Priority: Major
>
> According to the javadoc of DynamicFeature the callback method is to be
> invoked for relevant methods in resource or sub-resources. In the current
> implementation methods on sub-resource are NOT being invoked.
> {code:java}
> public class ResourceWithSubResource {
> @Path("/resource1")
> public SubResource getResource() {
> return new SubResource("Resource1: ");
> }
> }{code}
> {code:java}
> public class SubResource {
> public SubResource(String param) {
> _param = param;
> }
> @GET
> public String getParam() {
> return "Returning: " + _param;
> }
> @Path("/{path}")
> public SubResource subPath(@PathParam("path") String subPath) {
> return new SubResource(_param + "-" + subPath);
> }
> private String _param;
> }
> {code}
> in the provided example a _DynamicFeature_ is only invoked for
> _getResource()_ and it should also be invoked for relevant methods in
> _SubResource_.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7614) DynamicFeature is not invoked for sub resources
[
https://issues.apache.org/jira/browse/CXF-7614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16332128#comment-16332128
]
Carlos Sierra commented on CXF-7614:
hi Sergey,
in my current working copy of CXF's master, if I add the line:
{code:java}
sf.setStaticSubresourceResolution(true);{code}
to _org.apache.cxf.systest.jaxrs.BookServer#run_, just after setting the bus,
then the following tests fail:
{code:java}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running org.apache.cxf.systest.jaxrs.JAXRS20ClientServerBookTest
[INFO] Tests run: 43, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.239 s
- in org.apache.cxf.systest.jaxrs.JAXRS20ClientServerBookTest
[INFO] Running org.apache.cxf.systest.jaxrs.JAXRSAsyncClientTest
[INFO] Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 104.531
s - in org.apache.cxf.systest.jaxrs.JAXRSAsyncClientTest
[INFO] Running org.apache.cxf.systest.jaxrs.JAXRSAtomBookTest
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.143 s
- in org.apache.cxf.systest.jaxrs.JAXRSAtomBookTest
[INFO] Running org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest
[org.apache.cxf.systest.jaxrs.Book@1f1e58ca,
org.apache.cxf.systest.jaxrs.Book@1f1e58ca]
[ERROR] Tests run: 219, Failures: 2, Errors: 1, Skipped: 0, Time elapsed:
31.724 s <<< FAILURE! - in
org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest
[ERROR]
testGetBook123FromSubObject(org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest)
Time elapsed: 0.009 s <<< FAILURE!
java.lang.AssertionError: expected:<200> but was:<404>
at
org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest.getAndCompare(JAXRSClientServerBookTest.java:2755)
at
org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest.getAndCompareAsStrings(JAXRSClientServerBookTest.java:2733)
at
org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest.testGetBook123FromSubObject(JAXRSClientServerBookTest.java:2183)
[ERROR]
testUseParamBeanWebClientSubResource(org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest)
Time elapsed: 0.003 s <<< ERROR!
javax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error
at
org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest.doTestUseParamBeanWebClient(JAXRSClientServerBookTest.java:418)
at
org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest.testUseParamBeanWebClientSubResource(JAXRSClientServerBookTest.java:406)
[ERROR]
testUriInfoMatchedResourcesWithObject(org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest)
Time elapsed: 0.003 s <<< FAILURE!
java.lang.AssertionError: expected:<200> but was:<404>
at
org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest.getAndCompare(JAXRSClientServerBookTest.java:2755)
at
org.apache.cxf.systest.jaxrs.JAXRSClientServerBookTest.testUriInfoMatchedResourcesWithObject(JAXRSClientServerBookTest.java:2615)
[INFO] Running org.apache.cxf.systest.jaxrs.JAXRSClientServerNonSpringBookTest
[INFO] Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.295 s
- in org.apache.cxf.systest.jaxrs.JAXRSClientServerNonSpringBookTest
[INFO] Running org.apache.cxf.systest.jaxrs.JAXRSClientServerODataSearchTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.145 s
- in org.apache.cxf.systest.jaxrs.JAXRSClientServerODataSearchTest
[INFO] Running org.apache.cxf.systest.jaxrs.JAXRSClientServerProxySpringBookTest
PreDestroy called{code}
precisely the one that you mentioned.
If I remove that line from _org.apache.cxf.systest.jaxrs.BookServer#run_ then
the tests pass.
Don't you get the same output?
I guess this would be a bug then, as you mentioned.
> DynamicFeature is not invoked for sub resources
> ---
>
> Key: CXF-7614
> URL: https://issues.apache.org/jira/browse/CXF-7614
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Carlos Sierra
>Priority: Major
>
> According to the javadoc of DynamicFeature the callback method is to be
> invoked for relevant methods in resource or sub-resources. In the current
> implementation methods on sub-resource are NOT being invoked.
> {code:java}
> public class ResourceWithSubResource {
> @Path("/resource1")
> public SubResource getResource() {
> return new SubResource("Resource1: ");
> }
> }{code}
> {code:java}
> public class SubResource {
> public SubResource(String param) {
> _param = param;
> }
> @GET
> public String getParam() {
> return "Returning: " + _param;
> }
> @Path("/{path}")
> public SubResource subPath(@PathParam("path") String subPath) {
> return new SubResource(_param + "-" + subPath);
> }
> p
[jira] [Created] (CXF-7629) When registering a provider that implements MessageBodyReader and MessageBodyWriter interfaces through a Feature CXF ignores the interfaces in the contract and registers th
Carlos Sierra created CXF-7629:
--
Summary: When registering a provider that implements
MessageBodyReader and MessageBodyWriter interfaces through a Feature CXF
ignores the interfaces in the contract and registers them all
Key: CXF-7629
URL: https://issues.apache.org/jira/browse/CXF-7629
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.2.2
Reporter: Carlos Sierra
when using
{code:java}
javax.ws.rs.core.Configurable#register(java.lang.Object,
MessageBodyReader.class)
{code}
to register a provider that implements both MessageBodyReader and
MessageBodyWriter, CXF ignores the specified contract and registers the
provider for both MessageBodyReader and MessageBodyWriter, instead of only for
MessageBodyReader.class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7629) When registering a provider that implements MessageBodyReader and MessageBodyWriter interfaces through a Feature CXF ignores the interfaces in the contract and registers
[
https://issues.apache.org/jira/browse/CXF-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16348839#comment-16348839
]
Carlos Sierra commented on CXF-7629:
Looks like the logic in
org.apache.cxf.jaxrs.provider.ProviderFactory#setCommonProviders does not check
for the registered contracts but for the implemented interfaces. Could that be
the issue?
> When registering a provider that implements MessageBodyReader and
> MessageBodyWriter interfaces through a Feature CXF ignores the interfaces in
> the contract and registers them all
> --
>
> Key: CXF-7629
> URL: https://issues.apache.org/jira/browse/CXF-7629
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Carlos Sierra
>Priority: Major
>
> when using
>
> {code:java}
> javax.ws.rs.core.Configurable#register(java.lang.Object,
> MessageBodyReader.class)
> {code}
> to register a provider that implements both MessageBodyReader and
> MessageBodyWriter, CXF ignores the specified contract and registers the
> provider for both MessageBodyReader and MessageBodyWriter, instead of only
> for MessageBodyReader.class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7630) NameBindings are ignored for (at least) ContextResponseFilters
Carlos Sierra created CXF-7630:
--
Summary: NameBindings are ignored for (at least)
ContextResponseFilters
Key: CXF-7630
URL: https://issues.apache.org/jira/browse/CXF-7630
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.2.2
Reporter: Carlos Sierra
If we create a _NameBinding_ annotation:
{code:java}
@NameBinding
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface Filtered {
}{code}
and qualify a _ContainerResponseFilter_:
{code:java}
@Filtered
@Provider
public class TestNameBoundFilter implements ContainerResponseFilter {
@Override
public void filter(
ContainerRequestContext requestContext,
ContainerResponseContext responseContext)
throws IOException {
MultivaluedMap headers = responseContext.getHeaders();
headers.putSingle("NameBoundFiltered", "true");
}
}{code}
and some methods in a _Resource_:
{code:java}
public class NameBoundResource {
@GET
@Filtered
@Path("/filtered")
public String filtered() {
return "filtered";
}
@GET
@Path("/unfiltered")
public String unfiltered() {
return "unfiltered";
}
}{code}
only responses for requests made to _"/filtered"_ path should carry the
_"NameBoundHeader"_ header. However both responses, to _"/filtered"_ and
_"/unfiltered"_ carry the header.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7630) NameBindings are ignored for (at least) ContextResponseFilters
[
https://issues.apache.org/jira/browse/CXF-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16349010#comment-16349010
]
Carlos Sierra commented on CXF-7630:
I was actually looking at those and I thought that maybe they did not check for
_overbinding_. What do you mean by the "annotation visibility issue"? that may
be it.
> NameBindings are ignored for (at least) ContextResponseFilters
> --
>
> Key: CXF-7630
> URL: https://issues.apache.org/jira/browse/CXF-7630
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Carlos Sierra
>Priority: Major
>
> If we create a _NameBinding_ annotation:
> {code:java}
> @NameBinding
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.TYPE, ElementType.METHOD})
> public @interface Filtered {
> }{code}
> and qualify a _ContainerResponseFilter_:
> {code:java}
> @Filtered
> @Provider
> public class TestNameBoundFilter implements ContainerResponseFilter {
> @Override
> public void filter(
> ContainerRequestContext requestContext,
> ContainerResponseContext responseContext)
> throws IOException {
> MultivaluedMap headers = responseContext.getHeaders();
> headers.putSingle("NameBoundFiltered", "true");
> }
> }{code}
> and some methods in a _Resource_:
> {code:java}
> public class NameBoundResource {
> @GET
> @Filtered
> @Path("/filtered")
> public String filtered() {
> return "filtered";
> }
> @GET
> @Path("/unfiltered")
> public String unfiltered() {
> return "unfiltered";
> }
> }{code}
> only responses for requests made to _"/filtered"_ path should carry the
> _"NameBoundHeader"_ header. However both responses, to _"/filtered"_ and
> _"/unfiltered"_ carry the header.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7630) NameBindings are ignored for (at least) ContextResponseFilters
[
https://issues.apache.org/jira/browse/CXF-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16349050#comment-16349050
]
Carlos Sierra commented on CXF-7630:
I am checking the OperationMethodInfos and they correctly declare one of the
methods being bound and the other not bound. Does that help?
> NameBindings are ignored for (at least) ContextResponseFilters
> --
>
> Key: CXF-7630
> URL: https://issues.apache.org/jira/browse/CXF-7630
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Carlos Sierra
>Priority: Major
>
> If we create a _NameBinding_ annotation:
> {code:java}
> @NameBinding
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.TYPE, ElementType.METHOD})
> public @interface Filtered {
> }{code}
> and qualify a _ContainerResponseFilter_:
> {code:java}
> @Filtered
> @Provider
> public class TestNameBoundFilter implements ContainerResponseFilter {
> @Override
> public void filter(
> ContainerRequestContext requestContext,
> ContainerResponseContext responseContext)
> throws IOException {
> MultivaluedMap headers = responseContext.getHeaders();
> headers.putSingle("NameBoundFiltered", "true");
> }
> }{code}
> and some methods in a _Resource_:
> {code:java}
> public class NameBoundResource {
> @GET
> @Filtered
> @Path("/filtered")
> public String filtered() {
> return "filtered";
> }
> @GET
> @Path("/unfiltered")
> public String unfiltered() {
> return "unfiltered";
> }
> }{code}
> only responses for requests made to _"/filtered"_ path should carry the
> _"NameBoundHeader"_ header. However both responses, to _"/filtered"_ and
> _"/unfiltered"_ carry the header.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7630) NameBindings are ignored for (at least) ContextResponseFilters
[
https://issues.apache.org/jira/browse/CXF-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16349995#comment-16349995
]
Carlos Sierra commented on CXF-7630:
Hi again,
I think I have made progress and _@NameBinding_ seems to not work when the
filter is installed using a JAX-RS _Feature_. I am sorry I did not mention I am
using a Feature to register the filter.
I have sent a pull with a possible (possibly naive) fix to the problem.
Bests.
Carlos.
> NameBindings are ignored for (at least) ContextResponseFilters
> --
>
> Key: CXF-7630
> URL: https://issues.apache.org/jira/browse/CXF-7630
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Carlos Sierra
>Priority: Major
>
> If we create a _NameBinding_ annotation:
> {code:java}
> @NameBinding
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.TYPE, ElementType.METHOD})
> public @interface Filtered {
> }{code}
> and qualify a _ContainerResponseFilter_:
> {code:java}
> @Filtered
> @Provider
> public class TestNameBoundFilter implements ContainerResponseFilter {
> @Override
> public void filter(
> ContainerRequestContext requestContext,
> ContainerResponseContext responseContext)
> throws IOException {
> MultivaluedMap headers = responseContext.getHeaders();
> headers.putSingle("NameBoundFiltered", "true");
> }
> }{code}
> and some methods in a _Resource_:
> {code:java}
> public class NameBoundResource {
> @GET
> @Filtered
> @Path("/filtered")
> public String filtered() {
> return "filtered";
> }
> @GET
> @Path("/unfiltered")
> public String unfiltered() {
> return "unfiltered";
> }
> }{code}
> only responses for requests made to _"/filtered"_ path should carry the
> _"NameBoundHeader"_ header. However both responses, to _"/filtered"_ and
> _"/unfiltered"_ carry the header.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7630) NameBindings are ignored for (at least) ContextResponseFilters
[
https://issues.apache.org/jira/browse/CXF-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16350297#comment-16350297
]
Carlos Sierra commented on CXF-7630:
Sure...
thanks to you for all your support!
> NameBindings are ignored for (at least) ContextResponseFilters
> --
>
> Key: CXF-7630
> URL: https://issues.apache.org/jira/browse/CXF-7630
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Carlos Sierra
>Assignee: Sergey Beryozkin
>Priority: Major
> Fix For: 3.1.15, 3.2.2
>
>
> If we create a _NameBinding_ annotation:
> {code:java}
> @NameBinding
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.TYPE, ElementType.METHOD})
> public @interface Filtered {
> }{code}
> and qualify a _ContainerResponseFilter_:
> {code:java}
> @Filtered
> @Provider
> public class TestNameBoundFilter implements ContainerResponseFilter {
> @Override
> public void filter(
> ContainerRequestContext requestContext,
> ContainerResponseContext responseContext)
> throws IOException {
> MultivaluedMap headers = responseContext.getHeaders();
> headers.putSingle("NameBoundFiltered", "true");
> }
> }{code}
> and some methods in a _Resource_:
> {code:java}
> public class NameBoundResource {
> @GET
> @Filtered
> @Path("/filtered")
> public String filtered() {
> return "filtered";
> }
> @GET
> @Path("/unfiltered")
> public String unfiltered() {
> return "unfiltered";
> }
> }{code}
> only responses for requests made to _"/filtered"_ path should carry the
> _"NameBoundHeader"_ header. However both responses, to _"/filtered"_ and
> _"/unfiltered"_ carry the header.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7629) When registering a provider that implements MessageBodyReader and MessageBodyWriter interfaces through a Feature CXF ignores the interfaces in the contract and registers
[
https://issues.apache.org/jira/browse/CXF-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16350315#comment-16350315
]
Carlos Sierra commented on CXF-7629:
Hi Sergey,
I saw your fix and I was wondering if we should do the same for
_ContextResolver.class_ and _ParamConverterProvider.class_ so they are not
registered if not specified in the Configurable.
what do you think?
Carlos.
> When registering a provider that implements MessageBodyReader and
> MessageBodyWriter interfaces through a Feature CXF ignores the interfaces in
> the contract and registers them all
> --
>
> Key: CXF-7629
> URL: https://issues.apache.org/jira/browse/CXF-7629
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.2
>Reporter: Carlos Sierra
>Assignee: Sergey Beryozkin
>Priority: Major
> Fix For: 3.1.15, 3.2.2
>
>
> when using
>
> {code:java}
> javax.ws.rs.core.Configurable#register(java.lang.Object,
> MessageBodyReader.class)
> {code}
> to register a provider that implements both MessageBodyReader and
> MessageBodyWriter, CXF ignores the specified contract and registers the
> provider for both MessageBodyReader and MessageBodyWriter, instead of only
> for MessageBodyReader.class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7657) Reader and Writer interceptors are not sortered by the provider comparator
Carlos Sierra created CXF-7657: -- Summary: Reader and Writer interceptors are not sortered by the provider comparator Key: CXF-7657 URL: https://issues.apache.org/jira/browse/CXF-7657 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.2.2, 3.2.3 Reporter: Carlos Sierra Attachments: patch.diff ReaderInterceptors and WriterInterceptors are not sortered when a provider comparator is provided. Please see attached patch for a proposed (probably excessively naive) solution. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7657) Reader and Writer interceptors are not sorted by the provider comparator
[ https://issues.apache.org/jira/browse/CXF-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra updated CXF-7657: --- Summary: Reader and Writer interceptors are not sorted by the provider comparator (was: Reader and Writer interceptors are not sortered by the provider comparator) > Reader and Writer interceptors are not sorted by the provider comparator > > > Key: CXF-7657 > URL: https://issues.apache.org/jira/browse/CXF-7657 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.2.2, 3.2.3 >Reporter: Carlos Sierra >Priority: Major > Attachments: patch.diff > > > ReaderInterceptors and WriterInterceptors are not sortered when a provider > comparator is provided. > Please see attached patch for a proposed (probably excessively naive) > solution. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
