[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411452#comment-15411452
]
Vedran Pavic commented on CXF-6869:
---
Hi Sergey,
I've noticed yesterday that 3.1.7 was release two weeks ago (hint: neither [CXF
homepage|https://cxf.apache.org/] nor [downloads
page|https://cxf.apache.org/download.html] have a reference to it yet :)), so I
wanted to let you know CXF is now listed among Spring Boot's [3rd party
starters|https://github.com/spring-projects/spring-boot/tree/master/spring-boot-starters#community-contributions].
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>Assignee: Sergey Beryozkin
> Fix For: 3.1.7, 3.2.0
>
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7000) Allow logging to be enabled on-the-fly
Ingo Weiss created CXF-7000: --- Summary: Allow logging to be enabled on-the-fly Key: CXF-7000 URL: https://issues.apache.org/jira/browse/CXF-7000 Project: CXF Issue Type: Improvement Components: Core, logging Affects Versions: 3.1.7 Reporter: Ingo Weiss Allow the logging feature to be enabled on-the-fly without restarting the bus. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6998) Manual resolve ApplicationPath from parent classes as well.
[ https://issues.apache.org/jira/browse/CXF-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411607#comment-15411607 ] ASF GitHub Bot commented on CXF-6998: - Github user sberyozkin commented on the issue: https://github.com/apache/cxf/pull/154 Hi Andriy That spec statement is many years old, coming form 1.1 or earlier, before ApplicationPath was introduced (AFAIK) thus one may say well that statement does not apply to ApplicationPath as it is really about the resource classes and methods. (FYI, CXF checks class/interface level Path itself and never had any issues with various TCKs.) I'd say it should def be valid to have a custom Application extending another custom Application with ApplicationPath. So IMHO the patch is safe enough :-) Sergey > Manual resolve ApplicationPath from parent classes as well. > --- > > Key: CXF-6998 > URL: https://issues.apache.org/jira/browse/CXF-6998 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: John D. Ament > > The ApplicationPath annotation is not inherited. As a result, when proxies > are used (for things like CDI integration), those proxies do not have the > application path defined. As a result, the base URI is ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6992) ParamConverterProvider invoked with wrong types
[
https://issues.apache.org/jira/browse/CXF-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated CXF-6992:
--
Fix Version/s: 3.1.8
3.2.0
> ParamConverterProvider invoked with wrong types
> ---
>
> Key: CXF-6992
> URL: https://issues.apache.org/jira/browse/CXF-6992
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.5
>Reporter: Zoltan Farkas
> Fix For: 3.2.0, 3.1.8
>
>
> I have created a type: MyType
> and registered a ParameterConverterProvider to serialize/de-serialize my type.
> when I use my type as in a JAX-RS as:
> {code}
> @QueryParam("qparam") List>
> {code}
> end invoke the enpoint with:
> http://service/enpoint?qparam=abc&qparam=cde
> I get ParameterConverterProvider.getConverter(Integer.class,...) invoked
> instead of
> ParameterConverterProvider.getConverter(MyType.class,...)
> which does not look right to me, as such CXF tries to parse the qparam as
> Integer instead of MyType...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6997) Accept header doesn't correctly support multiple media ranges
[
https://issues.apache.org/jira/browse/CXF-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411619#comment-15411619
]
Sergey Beryozkin commented on CXF-6997:
---
Why
"MediaType.valueOf("application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5")"
is called ?
Are you calling it yourself ? If yes, then it is indeed wrong because MediaType
is not expected to process multiple media type values.
If not, the can you please provide mode details, the bigger exception trace,
what Produces value is set on the method, etc
> Accept header doesn't correctly support multiple media ranges
> -
>
> Key: CXF-6997
> URL: https://issues.apache.org/jira/browse/CXF-6997
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Jeff Moroski
>
> An Accept value of
> {{application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5}}
> is valid according to [Section 5.3.2 of RFC
> 7231|https://tools.ietf.org/html/rfc7231#section-5.3.2], but when a media
> range and no corresponding accept params exists anywhere but the end of the
> value, the MediaTypeHeaderProvider fails to process the value correctly:
> {noformat}
> Server stack trace: java.lang.IllegalArgumentException: Invalid media type
> string:
> application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.internalValueOf(MediaTypeHeaderProvider.java:90)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.valueOf(MediaTypeHeaderProvider.java:65)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:55)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:42)
> at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6997) Accept header doesn't correctly support multiple media ranges
[
https://issues.apache.org/jira/browse/CXF-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411619#comment-15411619
]
Sergey Beryozkin edited comment on CXF-6997 at 8/8/16 10:23 AM:
Why
"MediaType.valueOf("application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5")"
is called ?
Are you calling it yourself ? If yes, then it is indeed wrong because MediaType
is not expected to process multiple media type values.
If not, then can you please provide mode details, the bigger exception trace,
what Produces value is set on the method, etc
was (Author: sergey_beryozkin):
Why
"MediaType.valueOf("application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5")"
is called ?
Are you calling it yourself ? If yes, then it is indeed wrong because MediaType
is not expected to process multiple media type values.
If not, the can you please provide mode details, the bigger exception trace,
what Produces value is set on the method, etc
> Accept header doesn't correctly support multiple media ranges
> -
>
> Key: CXF-6997
> URL: https://issues.apache.org/jira/browse/CXF-6997
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Jeff Moroski
>
> An Accept value of
> {{application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5}}
> is valid according to [Section 5.3.2 of RFC
> 7231|https://tools.ietf.org/html/rfc7231#section-5.3.2], but when a media
> range and no corresponding accept params exists anywhere but the end of the
> value, the MediaTypeHeaderProvider fails to process the value correctly:
> {noformat}
> Server stack trace: java.lang.IllegalArgumentException: Invalid media type
> string:
> application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.internalValueOf(MediaTypeHeaderProvider.java:90)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.valueOf(MediaTypeHeaderProvider.java:65)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:55)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:42)
> at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6997) Accept header doesn't correctly support multiple media ranges
[
https://issues.apache.org/jira/browse/CXF-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411619#comment-15411619
]
Sergey Beryozkin edited comment on CXF-6997 at 8/8/16 10:23 AM:
Why is
"MediaType.valueOf("application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5")"
called ?
Are you calling it yourself ? If yes, then it is indeed wrong because MediaType
is not expected to process multiple media type values.
If not, then can you please provide mode details, the bigger exception trace,
what Produces value is set on the method, etc
was (Author: sergey_beryozkin):
Why
"MediaType.valueOf("application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5")"
is called ?
Are you calling it yourself ? If yes, then it is indeed wrong because MediaType
is not expected to process multiple media type values.
If not, then can you please provide mode details, the bigger exception trace,
what Produces value is set on the method, etc
> Accept header doesn't correctly support multiple media ranges
> -
>
> Key: CXF-6997
> URL: https://issues.apache.org/jira/browse/CXF-6997
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Jeff Moroski
>
> An Accept value of
> {{application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5}}
> is valid according to [Section 5.3.2 of RFC
> 7231|https://tools.ietf.org/html/rfc7231#section-5.3.2], but when a media
> range and no corresponding accept params exists anywhere but the end of the
> value, the MediaTypeHeaderProvider fails to process the value correctly:
> {noformat}
> Server stack trace: java.lang.IllegalArgumentException: Invalid media type
> string:
> application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.internalValueOf(MediaTypeHeaderProvider.java:90)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.valueOf(MediaTypeHeaderProvider.java:65)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:55)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:42)
> at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6998) Manual resolve ApplicationPath from parent classes as well.
[ https://issues.apache.org/jira/browse/CXF-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411684#comment-15411684 ] ASF GitHub Bot commented on CXF-6998: - Github user reta commented on the issue: https://github.com/apache/cxf/pull/154 👍 , sounds good to me, thanks @sberyozkin and @johnament ! > Manual resolve ApplicationPath from parent classes as well. > --- > > Key: CXF-6998 > URL: https://issues.apache.org/jira/browse/CXF-6998 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: John D. Ament > > The ApplicationPath annotation is not inherited. As a result, when proxies > are used (for things like CDI integration), those proxies do not have the > application path defined. As a result, the base URI is ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-6997) Accept header doesn't correctly support multiple media ranges
[
https://issues.apache.org/jira/browse/CXF-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411737#comment-15411737
]
Jeff Moroski edited comment on CXF-6997 at 8/8/16 12:36 PM:
No I'm not calling it myself, it's ultimately being called by
{{AbstractHTTPServlet.doGet()}} as part of a REST API call with that value
specified as an Accept header.
{noformat}
java.lang.IllegalArgumentException: Invalid media type string:
text/html,application/xhtml+xml,image/webp,application/xml;q=0.9,*/*;q=0.8
at
org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.internalValueOf(MediaTypeHeaderProvider.java:90)
at
org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.valueOf(MediaTypeHeaderProvider.java:65)
at
org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:55)
at
org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:42)
at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
at
com.vmware.vcloud.api.rest.providers.CustomResponseHandler.filter(CustomResponseHandler.java:81)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.runContainerResponseFilters(JAXRSUtils.java:1675)
at
org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.serializeMessage(JAXRSOutInterceptor.java:172)
at
org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.processResponse(JAXRSOutInterceptor.java:120)
at
org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage(JAXRSOutInterceptor.java:83)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at
org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:83)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:254)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
at
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:180)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:222)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at
com.vmware.vcloud.api.rest.jaxrs.servlet.CxfServlet.service(CxfServlet.java:171)
at
com.vmware.vcloud.api.rest.jaxrs.servlet.JaxRsDispatcherServlet.doService(JaxRsDispatcherServlet.java:93)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:951)
at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:842)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
{noformat}
I'm not sure why you say this isn't expected to process multiple media types.
This was a supported Accept header in 3.1.1, which we're currently upgrading
from, and the MediaTypeHeaderProvider specifically splits the value on the
comma char, which is the delimiter for multiple MediaTypes.
was (Author: jmoro...@vmware.com):
No I'm not calling it myself, it's ultimately being called by
{{AbstractHTTPServlet.doGet()}} as part of a REST API call with that value
specified as an Accept header.
{noformat}
java.lang.IllegalArgumentException: Invalid media type string:
text/html,application/xhtml+xml,image/webp,application/xml;q=0.9,*/*;q=0.8
at
org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.internalValueOf(MediaTypeHeaderProvider.java:90)
at
org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.valueOf(MediaTypeHeaderProvider.java:65)
at
org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:55)
at
org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:42)
at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
at
com.vmware.vcloud.api.rest.providers.CustomResponseHandler.filter(CustomResponseHandler.java:81)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.runContainerResponseFilters(JAXRSUtils.java:1675)
at
org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.serializeMessage(JAXRSOutInterceptor.java:172)
at
org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.processResponse(JAXRSOutInterceptor.java:120)
at
org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleM
[jira] [Commented] (CXF-6997) Accept header doesn't correctly support multiple media ranges
[
https://issues.apache.org/jira/browse/CXF-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411737#comment-15411737
]
Jeff Moroski commented on CXF-6997:
---
No I'm not calling it myself, it's ultimately being called by
{{AbstractHTTPServlet.doGet()}} as part of a REST API call with that value
specified as an Accept header.
{noformat}
java.lang.IllegalArgumentException: Invalid media type string:
text/html,application/xhtml+xml,image/webp,application/xml;q=0.9,*/*;q=0.8
at
org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.internalValueOf(MediaTypeHeaderProvider.java:90)
at
org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.valueOf(MediaTypeHeaderProvider.java:65)
at
org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:55)
at
org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:42)
at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
at
com.vmware.vcloud.api.rest.providers.CustomResponseHandler.filter(CustomResponseHandler.java:81)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.runContainerResponseFilters(JAXRSUtils.java:1675)
at
org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.serializeMessage(JAXRSOutInterceptor.java:172)
at
org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.processResponse(JAXRSOutInterceptor.java:120)
at
org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage(JAXRSOutInterceptor.java:83)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at
org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:83)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:254)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
at
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:180)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:298)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:222)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at
com.vmware.vcloud.api.rest.jaxrs.servlet.CxfServlet.service(CxfServlet.java:171)
at
com.vmware.vcloud.api.rest.jaxrs.servlet.JaxRsDispatcherServlet.doService(JaxRsDispatcherServlet.java:93)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:951)
at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:842)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
{noformat}
I'm not sure why you say this isn't expected to process multiple media types.
This was a supported Accept header in 3.1.1, which we're currently upgrading
from, and the MediaTypeHeaderProvider specifically splits the value on the
comma char, which is the delimiter for multiple MediaTypes.
> Accept header doesn't correctly support multiple media ranges
> -
>
> Key: CXF-6997
> URL: https://issues.apache.org/jira/browse/CXF-6997
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Jeff Moroski
>
> An Accept value of
> {{application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5}}
> is valid according to [Section 5.3.2 of RFC
> 7231|https://tools.ietf.org/html/rfc7231#section-5.3.2], but when a media
> range and no corresponding accept params exists anywhere but the end of the
> value, the MediaTypeHeaderProvider fails to process the value correctly:
> {noformat}
> Server stack trace: java.lang.IllegalArgumentException: Invalid media type
> string:
> application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.internalValueOf(MediaTypeHeaderProvider.java:90)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.valueOf(MediaTypeHeaderProvider.java:65)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:55)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:42)
> at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
> {noforma
[jira] [Updated] (CXF-6692) Update AbstractOAuthDataProvider to support JWT access tokens
[ https://issues.apache.org/jira/browse/CXF-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-6692: -- Summary: Update AbstractOAuthDataProvider to support JWT access tokens (was: Provide JwtTokenOAuthProvider) > Update AbstractOAuthDataProvider to support JWT access tokens > - > > Key: CXF-6692 > URL: https://issues.apache.org/jira/browse/CXF-6692 > Project: CXF > Issue Type: Improvement > Components: JAX-RS Security >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.8 > > > CXF already ships DefaultEncryptingOAuthProvider which can be used by the > servers to avoid storing the OAuth2 model, it uses a custom seriallization > format. It makes sense to offer a provider which uses a JWT token as a > properties container before encrypting it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6997) Accept header doesn't correctly support multiple media ranges
[
https://issues.apache.org/jira/browse/CXF-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411753#comment-15411753
]
Sergey Beryozkin commented on CXF-6997:
---
Hmm... See
https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/MediaTypeHeaderProvider.java
where does it split with a "," ?
Looking at the stack trace suggests a call is made from your custom response
filter, what do you do there ?
Thanks
> Accept header doesn't correctly support multiple media ranges
> -
>
> Key: CXF-6997
> URL: https://issues.apache.org/jira/browse/CXF-6997
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Jeff Moroski
>
> An Accept value of
> {{application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5}}
> is valid according to [Section 5.3.2 of RFC
> 7231|https://tools.ietf.org/html/rfc7231#section-5.3.2], but when a media
> range and no corresponding accept params exists anywhere but the end of the
> value, the MediaTypeHeaderProvider fails to process the value correctly:
> {noformat}
> Server stack trace: java.lang.IllegalArgumentException: Invalid media type
> string:
> application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.internalValueOf(MediaTypeHeaderProvider.java:90)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.valueOf(MediaTypeHeaderProvider.java:65)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:55)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:42)
> at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6997) Accept header doesn't correctly support multiple media ranges
[
https://issues.apache.org/jira/browse/CXF-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411773#comment-15411773
]
Jeff Moroski commented on CXF-6997:
---
Gah, you're right. I was getting my delimiters mixed up.
That value in the Accept header is actually built by multiple calls to
{{org.apache.cxf.jaxrs.client.AbstractClient.accept(String...)}}
Our JaxRsDispatcherServlet.doService does additional error reporting and
logging if JAX-RS applications aren't currently registered (this is an OSGi
environment), otherwise calls cxfServlet.service() for the typical flow. Our
CxfServlet extends CXFServlet, and in the case of the service() method, it is a
pure passthrough, doing nothing but calling the super implementation.
> Accept header doesn't correctly support multiple media ranges
> -
>
> Key: CXF-6997
> URL: https://issues.apache.org/jira/browse/CXF-6997
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Jeff Moroski
>
> An Accept value of
> {{application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5}}
> is valid according to [Section 5.3.2 of RFC
> 7231|https://tools.ietf.org/html/rfc7231#section-5.3.2], but when a media
> range and no corresponding accept params exists anywhere but the end of the
> value, the MediaTypeHeaderProvider fails to process the value correctly:
> {noformat}
> Server stack trace: java.lang.IllegalArgumentException: Invalid media type
> string:
> application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.internalValueOf(MediaTypeHeaderProvider.java:90)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.valueOf(MediaTypeHeaderProvider.java:65)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:55)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:42)
> at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CXF-6997) Accept header doesn't correctly support multiple media ranges
[
https://issues.apache.org/jira/browse/CXF-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Moroski updated CXF-6997:
--
Comment: was deleted
(was: Gah, you're right. I was getting my delimiters mixed up.
That value in the Accept header is actually built by multiple calls to
{{org.apache.cxf.jaxrs.client.AbstractClient.accept(String...)}}
Our JaxRsDispatcherServlet.doService does additional error reporting and
logging if JAX-RS applications aren't currently registered (this is an OSGi
environment), otherwise calls cxfServlet.service() for the typical flow. Our
CxfServlet extends CXFServlet, and in the case of the service() method, it is a
pure passthrough, doing nothing but calling the super implementation.)
> Accept header doesn't correctly support multiple media ranges
> -
>
> Key: CXF-6997
> URL: https://issues.apache.org/jira/browse/CXF-6997
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Jeff Moroski
>
> An Accept value of
> {{application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5}}
> is valid according to [Section 5.3.2 of RFC
> 7231|https://tools.ietf.org/html/rfc7231#section-5.3.2], but when a media
> range and no corresponding accept params exists anywhere but the end of the
> value, the MediaTypeHeaderProvider fails to process the value correctly:
> {noformat}
> Server stack trace: java.lang.IllegalArgumentException: Invalid media type
> string:
> application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.internalValueOf(MediaTypeHeaderProvider.java:90)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.valueOf(MediaTypeHeaderProvider.java:65)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:55)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:42)
> at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6997) Accept header doesn't correctly support multiple media ranges
[
https://issues.apache.org/jira/browse/CXF-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411779#comment-15411779
]
Jeff Moroski commented on CXF-6997:
---
Gah, you're right. I was getting my delimiters mixed up.
That value in the Accept header is actually built by multiple calls to
org.apache.cxf.jaxrs.client.AbstractClient.accept(String...)
The custom filtering apparently is calling MediaType.valueOf directly.
{code:java}
List mediaList = operationInfo.getProduceTypes();
List exchangeContentTypes =
(List)m.getExchange().get(Message.ACCEPT_CONTENT_TYPE);
assert exchangeContentTypes.size() > 0;
String mediaListValue = appendAllMediaTypes(exchangeContentTypes);
AcceptHeader accHeader = new AcceptHeader(mediaListValue);
List updatedMediaList =
replaceAnyTypeWithResponseMediaType(responseContext, mediaList);
MediaType assignableMedia = getAssignableMedia(updatedMediaList,
MediaType.valueOf(accHeader.toString()));
if (assignableMedia != null &&
!StringUtils.isEmpty(accHeader.getVersionAttribute())) {
responseContext.getHeaders().putSingle(HttpHeaders.CONTENT_TYPE,
assignableMedia);
}
{code}
Let me look into that more and see about working around the multi types there.
> Accept header doesn't correctly support multiple media ranges
> -
>
> Key: CXF-6997
> URL: https://issues.apache.org/jira/browse/CXF-6997
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Jeff Moroski
>
> An Accept value of
> {{application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5}}
> is valid according to [Section 5.3.2 of RFC
> 7231|https://tools.ietf.org/html/rfc7231#section-5.3.2], but when a media
> range and no corresponding accept params exists anywhere but the end of the
> value, the MediaTypeHeaderProvider fails to process the value correctly:
> {noformat}
> Server stack trace: java.lang.IllegalArgumentException: Invalid media type
> string:
> application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.internalValueOf(MediaTypeHeaderProvider.java:90)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.valueOf(MediaTypeHeaderProvider.java:65)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:55)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:42)
> at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6997) Accept header doesn't correctly support multiple media ranges
[
https://issues.apache.org/jira/browse/CXF-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411779#comment-15411779
]
Jeff Moroski edited comment on CXF-6997 at 8/8/16 1:11 PM:
---
Gah, you're right. I was getting my delimiters mixed up.
The custom filtering apparently is calling MediaType.valueOf directly.
{code:java}
List mediaList = operationInfo.getProduceTypes();
List exchangeContentTypes =
(List)m.getExchange().get(Message.ACCEPT_CONTENT_TYPE);
assert exchangeContentTypes.size() > 0;
String mediaListValue = appendAllMediaTypes(exchangeContentTypes);
AcceptHeader accHeader = new AcceptHeader(mediaListValue);
List updatedMediaList =
replaceAnyTypeWithResponseMediaType(responseContext, mediaList);
MediaType assignableMedia = getAssignableMedia(updatedMediaList,
MediaType.valueOf(accHeader.toString()));
if (assignableMedia != null &&
!StringUtils.isEmpty(accHeader.getVersionAttribute())) {
responseContext.getHeaders().putSingle(HttpHeaders.CONTENT_TYPE,
assignableMedia);
}
{code}
Let me look into that more and see about working around the multi types there.
That value in the Accept header is actually built by multiple calls to
org.apache.cxf.jaxrs.client.AbstractClient.accept(String...). Is there a
recommended way to handle the multiple types?
was (Author: jmoro...@vmware.com):
Gah, you're right. I was getting my delimiters mixed up.
That value in the Accept header is actually built by multiple calls to
org.apache.cxf.jaxrs.client.AbstractClient.accept(String...)
The custom filtering apparently is calling MediaType.valueOf directly.
{code:java}
List mediaList = operationInfo.getProduceTypes();
List exchangeContentTypes =
(List)m.getExchange().get(Message.ACCEPT_CONTENT_TYPE);
assert exchangeContentTypes.size() > 0;
String mediaListValue = appendAllMediaTypes(exchangeContentTypes);
AcceptHeader accHeader = new AcceptHeader(mediaListValue);
List updatedMediaList =
replaceAnyTypeWithResponseMediaType(responseContext, mediaList);
MediaType assignableMedia = getAssignableMedia(updatedMediaList,
MediaType.valueOf(accHeader.toString()));
if (assignableMedia != null &&
!StringUtils.isEmpty(accHeader.getVersionAttribute())) {
responseContext.getHeaders().putSingle(HttpHeaders.CONTENT_TYPE,
assignableMedia);
}
{code}
Let me look into that more and see about working around the multi types there.
> Accept header doesn't correctly support multiple media ranges
> -
>
> Key: CXF-6997
> URL: https://issues.apache.org/jira/browse/CXF-6997
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Jeff Moroski
>
> An Accept value of
> {{application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5}}
> is valid according to [Section 5.3.2 of RFC
> 7231|https://tools.ietf.org/html/rfc7231#section-5.3.2], but when a media
> range and no corresponding accept params exists anywhere but the end of the
> value, the MediaTypeHeaderProvider fails to process the value correctly:
> {noformat}
> Server stack trace: java.lang.IllegalArgumentException: Invalid media type
> string:
> application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.internalValueOf(MediaTypeHeaderProvider.java:90)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.valueOf(MediaTypeHeaderProvider.java:65)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:55)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:42)
> at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6997) Accept header doesn't correctly support multiple media ranges
[
https://issues.apache.org/jira/browse/CXF-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Moroski resolved CXF-6997.
---
Resolution: Not A Bug
This is user error. MediaType isn't intended to handle multiple media types in
a single value. Our calling code shouldn't be appending multiple accept
headers together into a single value.
> Accept header doesn't correctly support multiple media ranges
> -
>
> Key: CXF-6997
> URL: https://issues.apache.org/jira/browse/CXF-6997
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Jeff Moroski
>
> An Accept value of
> {{application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5}}
> is valid according to [Section 5.3.2 of RFC
> 7231|https://tools.ietf.org/html/rfc7231#section-5.3.2], but when a media
> range and no corresponding accept params exists anywhere but the end of the
> value, the MediaTypeHeaderProvider fails to process the value correctly:
> {noformat}
> Server stack trace: java.lang.IllegalArgumentException: Invalid media type
> string:
> application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.internalValueOf(MediaTypeHeaderProvider.java:90)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.valueOf(MediaTypeHeaderProvider.java:65)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:55)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:42)
> at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6997) Accept header doesn't correctly support multiple media ranges
[
https://issues.apache.org/jira/browse/CXF-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411800#comment-15411800
]
Sergey Beryozkin commented on CXF-6997:
---
Accept can indeed have multiple values but yes, MediaType.valueOf is meant to
process a single value (type, subtype, parameters) only
thanks
> Accept header doesn't correctly support multiple media ranges
> -
>
> Key: CXF-6997
> URL: https://issues.apache.org/jira/browse/CXF-6997
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.6
>Reporter: Jeff Moroski
>
> An Accept value of
> {{application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5}}
> is valid according to [Section 5.3.2 of RFC
> 7231|https://tools.ietf.org/html/rfc7231#section-5.3.2], but when a media
> range and no corresponding accept params exists anywhere but the end of the
> value, the MediaTypeHeaderProvider fails to process the value correctly:
> {noformat}
> Server stack trace: java.lang.IllegalArgumentException: Invalid media type
> string:
> application/*+xml,application/*+xml;version=25.0,application/*+xml;version=1.5
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.internalValueOf(MediaTypeHeaderProvider.java:90)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.valueOf(MediaTypeHeaderProvider.java:65)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:55)
> at
> org.apache.cxf.jaxrs.impl.MediaTypeHeaderProvider.fromString(MediaTypeHeaderProvider.java:42)
> at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6692) Update AbstractOAuthDataProvider to support JWT access tokens
[ https://issues.apache.org/jira/browse/CXF-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411801#comment-15411801 ] Sergey Beryozkin commented on CXF-6692: --- It should be configurable how to represent a token, for example, by default it is a binary value pointing to DB and the RS filters need to call the introspection service. Token in a JWS or JWE format becomes much more verbose - though RS may choose to validate it locally > Update AbstractOAuthDataProvider to support JWT access tokens > - > > Key: CXF-6692 > URL: https://issues.apache.org/jira/browse/CXF-6692 > Project: CXF > Issue Type: Improvement > Components: JAX-RS Security >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.8 > > > CXF already ships DefaultEncryptingOAuthProvider which can be used by the > servers to avoid storing the OAuth2 model, it uses a custom seriallization > format. It makes sense to offer a provider which uses a JWT token as a > properties container before encrypting it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411816#comment-15411816
]
Sergey Beryozkin commented on CXF-6869:
---
Hi Vedran, many thanks, I'm going to blog shortly about our joint effort.
Yes, CXF pages will be updated in the next couple of days
Cheers, Sergey
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>Assignee: Sergey Beryozkin
> Fix For: 3.1.7, 3.2.0
>
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7000) Allow logging to be enabled on-the-fly
[ https://issues.apache.org/jira/browse/CXF-7000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411919#comment-15411919 ] ASF GitHub Bot commented on CXF-7000: - GitHub user iweiss opened a pull request: https://github.com/apache/cxf/pull/155 [CXF-7000] Allow logging to be enabled on-the-fly The purpose of LiveLoggingInInterceptor/LiveLoggingOutInterceptor is to work as a marker and avoid removing any user's LoggingInInterceptor/LoggingOutInterceptor implementations. You can merge this pull request into a Git repository by running: $ git pull https://github.com/iweiss/cxf CXF-7000 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/155.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #155 commit bd9fc268b0ef2fe51ec717eb736d5b6a9ade5a25 Author: Ingo Weiss Date: 2016-08-08T13:00:21Z [CXF-7000] Allow logging to be enabled on-the-fly > Allow logging to be enabled on-the-fly > -- > > Key: CXF-7000 > URL: https://issues.apache.org/jira/browse/CXF-7000 > Project: CXF > Issue Type: Improvement > Components: Core, logging >Affects Versions: 3.1.7 >Reporter: Ingo Weiss > > Allow the logging feature to be enabled on-the-fly without restarting the bus. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412378#comment-15412378
]
Sergey Beryozkin commented on CXF-6869:
---
Hi Vedran
The link to the documentation
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
is wrong
it should be "http://cxf.apache.org/docs/springboot.html";
Can you please look into it ? I can easily create a PR myself too
Thanks, Sergey
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>Assignee: Sergey Beryozkin
> Fix For: 3.1.7, 3.2.0
>
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412378#comment-15412378
]
Sergey Beryozkin edited comment on CXF-6869 at 8/8/16 8:16 PM:
---
Hi Vedran
The link to the CXF SpringBoot documentation at
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
is wrong
it should be "http://cxf.apache.org/docs/springboot.html";
Can you please look into it ? I can easily create a PR myself too
Thanks, Sergey
was (Author: sergey_beryozkin):
Hi Vedran
The link to the documentation
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
is wrong
it should be "http://cxf.apache.org/docs/springboot.html";
Can you please look into it ? I can easily create a PR myself too
Thanks, Sergey
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>Assignee: Sergey Beryozkin
> Fix For: 3.1.7, 3.2.0
>
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6999) Undocumented IllegalArgumentException thrown on getAcceptableLanguages
[ https://issues.apache.org/jira/browse/CXF-6999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412393#comment-15412393 ] Sergey Beryozkin commented on CXF-6999: --- Hi, it may have been required by TCK. Can you please investigate how Jersey reacts in such cases ? thanks > Undocumented IllegalArgumentException thrown on getAcceptableLanguages > -- > > Key: CXF-6999 > URL: https://issues.apache.org/jira/browse/CXF-6999 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.0 >Reporter: Neeraj Krishna >Priority: Minor > > The following exception stack trace is observed when an user provides > incorrect language header and getAcceptableLanguages is invoked in the > implementation of ExceptionMapper > err] java.lang.IllegalArgumentException: Illegal locale value : zh-Hans-VN > 2016-08-02T09:48:39.691+0530 > [App/2] > err > [err] at org.apache.cxf.jaxrs.utils.HttpUtils.getLocale(HttpUtils.java:281) > 2016-08-02T09:48:39.692+0530 > [App/2] > err > [err] at > org.apache.cxf.jaxrs.utils.ExceptionUtils.convertFaultToResponse(ExceptionUtils.java:86) > 2016-08-02T09:48:39.692+0530 > [App/2] > err > [err] at > org.apache.cxf.jaxrs.impl.tl.ThreadLocalHttpHeaders.getAcceptableLanguages(ThreadLocalHttpHeaders.java:57) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412395#comment-15412395
]
Vedran Pavic commented on CXF-6869:
---
Hi Sergey,
The link is actually OK - first column in the table links to the Apache CXF
page while second links to the Github repo.
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>Assignee: Sergey Beryozkin
> Fix For: 3.1.7, 3.2.0
>
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412395#comment-15412395
]
Vedran Pavic edited comment on CXF-6869 at 8/8/16 8:23 PM:
---
Hi Sergey,
The link is actually OK - first column in the table links to the Apache CXF
page while second column links to the Github repo.
was (Author: vpavic):
Hi Sergey,
The link is actually OK - first column in the table links to the Apache CXF
page while second links to the Github repo.
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>Assignee: Sergey Beryozkin
> Fix For: 3.1.7, 3.2.0
>
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412397#comment-15412397
]
Sergey Beryozkin commented on CXF-6869:
---
LOL, silly me, I'm glad I did not create a patch request to fix it :-)
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>Assignee: Sergey Beryozkin
> Fix For: 3.1.7, 3.2.0
>
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7001) Update JAX-RS SpringBoot starter to support scanning JAX-RS Applications
Sergey Beryozkin created CXF-7001: - Summary: Update JAX-RS SpringBoot starter to support scanning JAX-RS Applications Key: CXF-7001 URL: https://issues.apache.org/jira/browse/CXF-7001 Project: CXF Issue Type: Improvement Components: JAX-RS Reporter: Sergey Beryozkin Priority: Minor Fix For: 3.2.0, 3.1.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412407#comment-15412407
]
Vedran Pavic commented on CXF-6869:
---
No problem.
You got me confused for a moment too :)
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>Assignee: Sergey Beryozkin
> Fix For: 3.1.7, 3.2.0
>
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6998) Manual resolve ApplicationPath from parent classes as well.
[ https://issues.apache.org/jira/browse/CXF-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412660#comment-15412660 ] ASF GitHub Bot commented on CXF-6998: - Github user asfgit closed the pull request at: https://github.com/apache/cxf/pull/154 > Manual resolve ApplicationPath from parent classes as well. > --- > > Key: CXF-6998 > URL: https://issues.apache.org/jira/browse/CXF-6998 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: John D. Ament > > The ApplicationPath annotation is not inherited. As a result, when proxies > are used (for things like CDI integration), those proxies do not have the > application path defined. As a result, the base URI is ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6998) Manual resolve ApplicationPath from parent classes as well.
[ https://issues.apache.org/jira/browse/CXF-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-6998. --- Resolution: Fixed Assignee: Andriy Redko > Manual resolve ApplicationPath from parent classes as well. > --- > > Key: CXF-6998 > URL: https://issues.apache.org/jira/browse/CXF-6998 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: John D. Ament >Assignee: Andriy Redko > > The ApplicationPath annotation is not inherited. As a result, when proxies > are used (for things like CDI integration), those proxies do not have the > application path defined. As a result, the base URI is ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-6991) WS-RM - Request context properties are lost when sending subsequent protocol message
[
https://issues.apache.org/jira/browse/CXF-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-6991:
-
Assignee: Freeman Fang
> WS-RM - Request context properties are lost when sending subsequent protocol
> message
>
>
> Key: CXF-6991
> URL: https://issues.apache.org/jira/browse/CXF-6991
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 2.7.18, 3.1.7
>Reporter: Tomohisa Igarashi
>Assignee: Freeman Fang
> Attachments: cxf-ws-rm-context-property.tgz
>
>
> We hit "No SAML CallbackHandler available" error when it's sending
> TerminateSequence.
> {code}
> 20:44:32,416 SEVERE [org.apache.cxf.ws.rm.Proxy] (default-workqueue-1) Failed
> to send RM protocol message
> {http://schemas.xmlsoap.org/ws/2005/02/rm}TerminateSequence.:
> org.apache.cxf.interceptor.Fault: No SAML CallbackHandler available
> at
> org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:198)
> [cxf-rt-ws-security-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at
> org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.handleBinding(AsymmetricBindingHandler.java:98)
> [cxf-rt-ws-security-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at
> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:176)
> [cxf-rt-ws-security-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at
> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:90)
> [cxf-rt-ws-security-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> [cxf-api-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:572)
> [cxf-api-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:481)
> [cxf-api-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:393)
> [cxf-api-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at org.apache.cxf.ws.rm.Proxy.invoke(Proxy.java:295)
> [cxf-rt-ws-rm-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at org.apache.cxf.ws.rm.Proxy.terminate(Proxy.java:101)
> [cxf-rt-ws-rm-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at
> org.apache.cxf.ws.rm.SourceSequence.setAcknowledged(SourceSequence.java:159)
> [cxf-rt-ws-rm-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at
> org.apache.cxf.ws.rm.RMInInterceptor.processAcknowledgments(RMInInterceptor.java:191)
> [cxf-rt-ws-rm-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at
> org.apache.cxf.ws.rm.RMInInterceptor.handle(RMInInterceptor.java:163)
> [cxf-rt-ws-rm-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at
> org.apache.cxf.ws.rm.AbstractRMInterceptor.handleMessage(AbstractRMInterceptor.java:83)
> [cxf-rt-ws-rm-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> [cxf-api-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:831)
> [cxf-api-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1642)
> [cxf-rt-transports-http-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream$1.run(HTTPConduit.java:1133)
> [cxf-rt-transports-http-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:428)
> [cxf-api-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [rt.jar:1.8.0_101]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [rt.jar:1.8.0_101]
> at
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:353)
> [cxf-api-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_101]
> Caused by: org.apache.cxf.ws.policy.PolicyException: No SAML CallbackHandler
> available
> at
> org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:315)
> [cxf-rt-ws-security-2.7.18.redhat-1.jar:2.7.18.redhat-1]
> at
> org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.addSamlToken(AbstractBindingBuilder.java:923)
> [cxf-r
[jira] [Created] (CXF-7002) Add isExpired method in JettyContinuationWrapper
onder sezgin created CXF-7002: - Summary: Add isExpired method in JettyContinuationWrapper Key: CXF-7002 URL: https://issues.apache.org/jira/browse/CXF-7002 Project: CXF Issue Type: Improvement Components: Transports Affects Versions: 3.1.7 Reporter: onder sezgin Fix For: 3.2.0, 3.1.8 CAMEL-10171 has memory leak, and before avoiding memory leak, i want to implement some missing methods to propagate the continuation timeout by adding some methods like isExpired in org.apache.cxf.transport.http_jetty.continuations.JettyContinuationWrapper -- This message was sent by Atlassian JIRA (v6.3.4#6332)
