[jira] [Created] (CXF-6990) Swagger tags not sorted if using Swagger2Feature
Francesco Chicchiriccò created CXF-6990:
---
Summary: Swagger tags not sorted if using Swagger2Feature
Key: CXF-6990
URL: https://issues.apache.org/jira/browse/CXF-6990
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.0.10, 3.1.7, 3.2.0
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
Fix For: 3.1.8
With latest updates, the tags generated by {{Swagger2Serializers}} for
{{swagger.json}} (e.g when using {{Swagger2Feature}}) appear not to be sorted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6990) Swagger tags not sorted if using Swagger2Feature
[
https://issues.apache.org/jira/browse/CXF-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated CXF-6990:
Priority: Minor (was: Major)
> Swagger tags not sorted if using Swagger2Feature
>
>
> Key: CXF-6990
> URL: https://issues.apache.org/jira/browse/CXF-6990
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.10, 3.1.7, 3.2.0
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
>Priority: Minor
> Fix For: 3.1.8
>
>
> With latest updates, the tags generated by {{Swagger2Serializers}} for
> {{swagger.json}} (e.g when using {{Swagger2Feature}}) appear not to be sorted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6990) Swagger tags not sorted if using Swagger2Feature
[
https://issues.apache.org/jira/browse/CXF-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò resolved CXF-6990.
-
Resolution: Fixed
> Swagger tags not sorted if using Swagger2Feature
>
>
> Key: CXF-6990
> URL: https://issues.apache.org/jira/browse/CXF-6990
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.10, 3.1.7, 3.2.0
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
>Priority: Minor
> Fix For: 3.1.8
>
>
> With latest updates, the tags generated by {{Swagger2Serializers}} for
> {{swagger.json}} (e.g when using {{Swagger2Feature}}) appear not to be sorted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6990) Swagger tags not sorted if using Swagger2Feature
[
https://issues.apache.org/jira/browse/CXF-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated CXF-6990:
Fix Version/s: 3.0.11
3.2.0
> Swagger tags not sorted if using Swagger2Feature
>
>
> Key: CXF-6990
> URL: https://issues.apache.org/jira/browse/CXF-6990
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.10, 3.1.7, 3.2.0
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
>Priority: Minor
> Fix For: 3.2.0, 3.1.8, 3.0.11
>
>
> With latest updates, the tags generated by {{Swagger2Serializers}} for
> {{swagger.json}} (e.g when using {{Swagger2Feature}}) appear not to be sorted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6454) Orphaned JMS connections created in endless loop
[
https://issues.apache.org/jira/browse/CXF-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated CXF-6454:
--
Fix Version/s: (was: 3.1.7)
> Orphaned JMS connections created in endless loop
>
>
> Key: CXF-6454
> URL: https://issues.apache.org/jira/browse/CXF-6454
> Project: CXF
> Issue Type: Bug
> Components: JMS, Transports
>Affects Versions: 3.0.5
>Reporter: Waldemar Szostak
>Assignee: Christian Schneider
>Priority: Critical
> Fix For: 3.0.7, 3.2.0
>
>
> h3. Problem description
> In JMSFactory.createConnection(JMSConfiguration):
> {code}public static Connection createConnection(JMSConfiguration jmsConfig)
> throws JMSException {
> String username = jmsConfig.getUserName();
> ConnectionFactory cf = jmsConfig.getConnectionFactory();
> Connection connection = username != null
> ? cf.createConnection(username, jmsConfig.getPassword())
> : cf.createConnection();
> if (jmsConfig.getDurableSubscriptionClientId() != null) {
>
> connection.setClientID(jmsConfig.getDurableSubscriptionClientId());
> }
> return connection;
> }{code}
> there is no exception handling if the clientID fails to be set. Such an
> exception would exit this method without passing the reference to the
> just-opened JMS connection to exception handling code
> (JMSDestination.createTargetDestinationListener()).
> Moreover, JMSDestination.restartConnection() keeps on starting new
> connections (there is no max attempt restriction!) until it creates one
> without an exception thrown in the process.
> Now, if the clientID is already connected to the ESB, this creation of new
> connection will last until server resources are no longer available to the
> JVM.
> h3. Possible solution
> # Close the connection if it's not possible to set the specified clientID at
> the time:
> {code}public static Connection createConnection(JMSConfiguration jmsConfig)
> throws JMSException {
> String username = jmsConfig.getUserName();
> ConnectionFactory cf = jmsConfig.getConnectionFactory();
> Connection connection = username != null
> ? cf.createConnection(username,
> jmsConfig.getPassword())
> : cf.createConnection();
> if (jmsConfig.getDurableSubscriptionClientId() != null) {
> try {
> connection.setClientID(jmsConfig.getDurableSubscriptionClientId());
> } catch (InvalidClientIDException e) {
> connection.close();
> throw e;
> }
> }
> return connection;
> }{code}
> # Add a setting to restrict the maximum attempts to restart the connection in
> JMSDestination.restartConnection() A configurable value would be best, but
> even a hardcoded.. anything but the practically endless loop ;-)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-6979) NPE in AbstractHTTPDestination.invoke when service is invoked very early
[ https://issues.apache.org/jira/browse/CXF-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-6979: -- Fix Version/s: (was: 3.1.7) > NPE in AbstractHTTPDestination.invoke when service is invoked very early > > > Key: CXF-6979 > URL: https://issues.apache.org/jira/browse/CXF-6979 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.1.6 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 3.2.0 > > > Happens when doing mvn clean install in DOSGi. > It seems the incomingObserver is still null at this point. A possible fix is > to set the observer before starting the endpoint. > java.lang.NullPointerException > at > org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:254) > http://apaste.info/xk7 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6979) NPE in AbstractHTTPDestination.invoke when service is invoked very early
[ https://issues.apache.org/jira/browse/CXF-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-6979: -- Hi Christian, this was automatically moved to 3.2.0 when I marked 3.1.7 as being released, please resolve it for 3.1.7/3.2.0 if you are happy with the NPE guard > NPE in AbstractHTTPDestination.invoke when service is invoked very early > > > Key: CXF-6979 > URL: https://issues.apache.org/jira/browse/CXF-6979 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.1.6 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 3.2.0 > > > Happens when doing mvn clean install in DOSGi. > It seems the incomingObserver is still null at this point. A possible fix is > to set the observer before starting the endpoint. > java.lang.NullPointerException > at > org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:254) > http://apaste.info/xk7 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6454) Orphaned JMS connections created in endless loop
[
https://issues.apache.org/jira/browse/CXF-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407509#comment-15407509
]
Sergey Beryozkin commented on CXF-6454:
---
Hi Christian, this was automatically moved to 3.2.0 when I marked 3.1.7 as
being released
> Orphaned JMS connections created in endless loop
>
>
> Key: CXF-6454
> URL: https://issues.apache.org/jira/browse/CXF-6454
> Project: CXF
> Issue Type: Bug
> Components: JMS, Transports
>Affects Versions: 3.0.5
>Reporter: Waldemar Szostak
>Assignee: Christian Schneider
>Priority: Critical
> Fix For: 3.0.7, 3.2.0
>
>
> h3. Problem description
> In JMSFactory.createConnection(JMSConfiguration):
> {code}public static Connection createConnection(JMSConfiguration jmsConfig)
> throws JMSException {
> String username = jmsConfig.getUserName();
> ConnectionFactory cf = jmsConfig.getConnectionFactory();
> Connection connection = username != null
> ? cf.createConnection(username, jmsConfig.getPassword())
> : cf.createConnection();
> if (jmsConfig.getDurableSubscriptionClientId() != null) {
>
> connection.setClientID(jmsConfig.getDurableSubscriptionClientId());
> }
> return connection;
> }{code}
> there is no exception handling if the clientID fails to be set. Such an
> exception would exit this method without passing the reference to the
> just-opened JMS connection to exception handling code
> (JMSDestination.createTargetDestinationListener()).
> Moreover, JMSDestination.restartConnection() keeps on starting new
> connections (there is no max attempt restriction!) until it creates one
> without an exception thrown in the process.
> Now, if the clientID is already connected to the ESB, this creation of new
> connection will last until server resources are no longer available to the
> JVM.
> h3. Possible solution
> # Close the connection if it's not possible to set the specified clientID at
> the time:
> {code}public static Connection createConnection(JMSConfiguration jmsConfig)
> throws JMSException {
> String username = jmsConfig.getUserName();
> ConnectionFactory cf = jmsConfig.getConnectionFactory();
> Connection connection = username != null
> ? cf.createConnection(username,
> jmsConfig.getPassword())
> : cf.createConnection();
> if (jmsConfig.getDurableSubscriptionClientId() != null) {
> try {
> connection.setClientID(jmsConfig.getDurableSubscriptionClientId());
> } catch (InvalidClientIDException e) {
> connection.close();
> throw e;
> }
> }
> return connection;
> }{code}
> # Add a setting to restrict the maximum attempts to restart the connection in
> JMSDestination.restartConnection() A configurable value would be best, but
> even a hardcoded.. anything but the practically endless loop ;-)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6979) NPE in AbstractHTTPDestination.invoke when service is invoked very early
[ https://issues.apache.org/jira/browse/CXF-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved CXF-6979. -- Resolution: Fixed Fix Version/s: (was: 3.2.0) 3.1.7 I think this should be done > NPE in AbstractHTTPDestination.invoke when service is invoked very early > > > Key: CXF-6979 > URL: https://issues.apache.org/jira/browse/CXF-6979 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.1.6 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 3.1.7 > > > Happens when doing mvn clean install in DOSGi. > It seems the incomingObserver is still null at this point. A possible fix is > to set the observer before starting the endpoint. > java.lang.NullPointerException > at > org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:254) > http://apaste.info/xk7 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6989) Content Disposition does not handle "=" in filename
[ https://issues.apache.org/jira/browse/CXF-6989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407540#comment-15407540 ] ASF GitHub Bot commented on CXF-6989: - Github user sberyozkin commented on the issue: https://github.com/apache/cxf/pull/151 Thanks for the patch. Would it be possible to avoid bringing in a new dependency only to make it easier to deal with this case ? > Content Disposition does not handle "=" in filename > --- > > Key: CXF-6989 > URL: https://issues.apache.org/jira/browse/CXF-6989 > Project: CXF > Issue Type: Bug > Components: Core >Reporter: Kevin Osborn > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6880) ODATA Parser : searching object from Id of its nested object failed
[ https://issues.apache.org/jira/browse/CXF-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-6880: -- Component/s: JAX-RS > ODATA Parser : searching object from Id of its nested object failed > --- > > Key: CXF-6880 > URL: https://issues.apache.org/jira/browse/CXF-6880 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.6 > Environment: Jdk 1.8, Spring, JPA, REST >Reporter: Frederic MONCLAR >Priority: Blocker > Attachments: class hierarchy.png > > > Hi, > I'm using odata parser to manage odata request. When I'm doing a simple > request as : $filter=id eq 1 on object entity containing id parameter, the > matching type action is resolved, but when I'm doing it again on a nested > object on the same parameter type as : $filter=call.id eq 1 it failed. > I'm getting the following exception : > 2016-04-25 12:20:12.728 INFO 12020 --- [nio-8081-exec-1] > o.a.c.c.C.[.[.[/api/business/v0] : Initializing Spring > FrameworkServlet 'dispatcherServlet' > 2016-04-25 12:20:12.768 DEBUG 12020 --- [nio-8081-exec-1] > o.s.b.c.web.OrderedRequestContextFilter : Bound request context to thread: > org.apache.catalina.connector.RequestFacade@35a2318d > 2016-04-25 12:20:13.235 DEBUG 12020 --- [nio-8081-exec-1] > o.s.b.c.web.OrderedRequestContextFilter : Cleared thread-bound request > context: org.apache.catalina.connector.RequestFacade@35a2318d > 2016-04-25 12:20:13.239 ERROR 12020 --- [nio-8081-exec-1] > o.a.c.c.C.[.[.[.[dispatcherServlet] : Servlet.service() for servlet > [dispatcherServlet] in context with path [/api/business/v0] threw exception > [Request processing failed; nested exception is > fr.gyptis.ci5.backend.commons.exception.RequestException: > org.apache.cxf.jaxrs.ext.search.SearchParseException: Cannot convert String > value "1" to a value of class > fr.gyptis.ci5.backend.business.dao.entities.Call] with root cause > java.lang.NoSuchMethodException: java.io.Serializable.() > at java.lang.Class.getConstructor0(Class.java:3082) ~[na:1.8.0_72] > at java.lang.Class.newInstance(Class.java:412) ~[na:1.8.0_72] > at > org.apache.cxf.jaxrs.ext.search.AbstractSearchConditionParser.parseType(AbstractSearchConditionParser.java:208) > ~[cxf-rt-rs-extension-search-3.1.6.jar:3.1.6] > at > org.apache.cxf.jaxrs.ext.search.odata.ODataParser.access$600(ODataParser.java:61) > ~[cxf-rt-rs-extension-search-3.1.6.jar:3.1.6] > at > org.apache.cxf.jaxrs.ext.search.odata.ODataParser$FilterExpressionVisitor.visitBinary(ODataParser.java:173) > ~[cxf-rt-rs-extension-search-3.1.6.jar:3.1.6] > at > org.apache.olingo.odata2.core.uri.expression.BinaryExpressionImpl.accept(BinaryExpressionImpl.java:90) > ~[olingo-odata2-core-2.0.6.jar:2.0.6] > at > org.apache.olingo.odata2.core.uri.expression.FilterExpressionImpl.accept(FilterExpressionImpl.java:58) > ~[olingo-odata2-core-2.0.6.jar:2.0.6] > at > org.apache.cxf.jaxrs.ext.search.odata.ODataParser.parse(ODataParser.java:286) > ~[cxf-rt-rs-extension-search-3.1.6.jar:3.1.6] > at > fr.gyptis.ci5.backend.business.init.SearchContext.getCondition(SearchContext.java:118) > ~[classes/:na] > at > fr.gyptis.ci5.backend.business.init.SearchContext.getCondition(SearchContext.java:99) > ~[classes/:na] > at > fr.gyptis.ci5.backend.business.init.SearchContext.getCondition(SearchContext.java:94) > ~[classes/:na] > at > fr.gyptis.ci5.backend.business.init.SearchContext.getCondition(SearchContext.java:81) > ~[classes/:na] > at > fr.gyptis.ci5.backend.business.dao.facade.impl.CallHeaderDaoImpl.findAllByCriteria(CallHeaderDaoImpl.java:45) > ~[classes/:na] > at > fr.gyptis.ci5.backend.business.resources.CallHeaderResource.findAll(CallHeaderResource.java:81) > ~[classes/:na] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ~[na:1.8.0_72] > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ~[na:1.8.0_72] > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ~[na:1.8.0_72] > at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_72] > at > org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:222) > ~[spring-web-4.2.4.RELEASE.jar:4.2.4.RELEASE] > at > org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:137) > ~[spring-web-4.2.4.RELEASE.jar:4.2.4.RELEASE] > at > org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:110) > ~[spring-webmvc-4.2.4.RELEASE.jar:4.2.4.RELEASE]
[jira] [Created] (CXF-6991) WS-RM - Request context properties are lost when sending subsequent protocol message
Tomohisa Igarashi created CXF-6991:
--
Summary: 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: 3.1.7, 2.7.18
Reporter: Tomohisa Igarashi
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-rt-ws-security-2.7.18.redhat-1.jar:2.7.18.redhat-1]
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.handleSupportingTokens(AbstractBindingBuilder.java:571)
[cxf-rt-ws-security-2.7.18.redhat-1.jar:2.7.18.redhat-1]
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.handleSupportingTokens(AbstractBindingBuilder.java:455)
[cxf-rt-ws-security-2.7.18.redh
[jira] [Updated] (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
]
Tomohisa Igarashi updated CXF-6991:
---
Attachment: cxf-ws-rm-context-property.tgz
Attaching a unit test [^cxf-ws-rm-context-property.tgz].
It has 2 test method, test() and testContextProperty(). test() uses
GreeterCombinedClient which has ws-security properties on its definition. On
the other hand the testContextProperty() uses GreeterCombinedClientNoProperty
which doesn't have properties, but they are passed as request context
properties instead. You'll see following error only in testContextProperty().
test() finishes without this error.
{code}
2016-08-04 17:49:56.891 SEVERE [org.apache.cxf.ws.rm.Proxy] Failed to send RM
protocol message
{http://schemas.xmlsoap.org/ws/2005/02/rm}SequenceAcknowledgement.
(org.apache.cxf.ws.rm.Proxy invoke)
org.apache.cxf.interceptor.Fault: Security configuration could not be detected.
Potential cause: Make sure jaxws:client element with name attribute value
matching endpoint port is defined as well as a ws-security.signature.properties
element within it.
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:198)
(...snip...)
Caused by: org.apache.cxf.ws.policy.PolicyException: Security configuration
could not be detected. Potential cause: Make sure jaxws:client element with
name attribute value matching endpoint port is defined as well as a
ws-security.signature.properties element within it.
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:315)
{code}
It's not exactly same error though, looks similar as both can't find the
properties passed in as request context properties when it's sending subsequent
WS-RM protocol message (SequenceAcknowledgement in the unit test). Since both
of TerminateSequence and SequenceAcknowledgement are sent by background thread,
I guess something wrong happens while transferring context between those
threads.
> 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
> 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)
[jira] [Created] (CXF-6992) ParamConverterProvider invoked with wrong types
Zoltan Farkas created CXF-6992:
--
Summary: 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
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] [Created] (CXF-6993) JweJsonProducer does not support multiple recipients if CEK is auto-generated
Sergey Beryozkin created CXF-6993: - Summary: JweJsonProducer does not support multiple recipients if CEK is auto-generated Key: CXF-6993 URL: https://issues.apache.org/jira/browse/CXF-6993 Project: CXF Issue Type: Bug Reporter: Sergey Beryozkin Priority: Minor Fix For: 3.2.0, 3.1.8 It should notify the CEK provider that CEK should be auto-generated only once -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6994) RMCaptureInInterceptor running on GET requests
Alessio Soldano created CXF-6994: Summary: RMCaptureInInterceptor running on GET requests Key: CXF-6994 URL: https://issues.apache.org/jira/browse/CXF-6994 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 3.1.7 Reporter: Alessio Soldano Fix For: 3.1.8 The changes at https://github.com/apache/cxf/commit/0dd29509e42fc412ec0cf214e66885d26da9850e are causing a regression in case of (wsdl) get requests being processed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6994) RMCaptureInInterceptor running on GET requests
[ https://issues.apache.org/jira/browse/CXF-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408062#comment-15408062 ] ASF GitHub Bot commented on CXF-6994: - GitHub user asoldano opened a pull request: https://github.com/apache/cxf/pull/152 [CXF-6994] Skip RMCaptureInInterceptor processing for GET requests You can merge this pull request into a Git repository by running: $ git pull https://github.com/asoldano/cxf CXF-6994 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/152.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 #152 commit 57d9d556066372fef3cde1589acb570e543b78df Author: Alessio Soldano Date: 2016-08-04T16:31:05Z [CXF-6994] Skip RMCaptureInInterceptor processing for GET requests > RMCaptureInInterceptor running on GET requests > -- > > Key: CXF-6994 > URL: https://issues.apache.org/jira/browse/CXF-6994 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.7 >Reporter: Alessio Soldano > Fix For: 3.1.8 > > > The changes at > https://github.com/apache/cxf/commit/0dd29509e42fc412ec0cf214e66885d26da9850e > are causing a regression in case of (wsdl) get requests being processed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6994) RMCaptureInInterceptor running on GET requests
[ https://issues.apache.org/jira/browse/CXF-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408063#comment-15408063 ] Alessio Soldano commented on CXF-6994: -- PR: https://github.com/apache/cxf/pull/152 > RMCaptureInInterceptor running on GET requests > -- > > Key: CXF-6994 > URL: https://issues.apache.org/jira/browse/CXF-6994 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.1.7 >Reporter: Alessio Soldano > Fix For: 3.1.8 > > > The changes at > https://github.com/apache/cxf/commit/0dd29509e42fc412ec0cf214e66885d26da9850e > are causing a regression in case of (wsdl) get requests being processed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6989) Content Disposition does not handle "=" in filename
[ https://issues.apache.org/jira/browse/CXF-6989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408201#comment-15408201 ] ASF GitHub Bot commented on CXF-6989: - Github user osbornk commented on the issue: https://github.com/apache/cxf/pull/151 Unfortunately, dealing with possibly quoted text is not entirely trivial. That is why I brought in StrTokenizer. It handles this case really well. There is a decent amount of code involved in tokenization. So, that is why I had to introduce this dependency. > Content Disposition does not handle "=" in filename > --- > > Key: CXF-6989 > URL: https://issues.apache.org/jira/browse/CXF-6989 > Project: CXF > Issue Type: Bug > Components: Core >Reporter: Kevin Osborn > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider classes attribute of application when using CDI
[ https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408637#comment-15408637 ] ASF GitHub Bot commented on CXF-6987: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/149 Jenkins retest this please > Consider classes attribute of application when using CDI > > > Key: CXF-6987 > URL: https://issues.apache.org/jira/browse/CXF-6987 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > CXF's CDI integration integration assumes that all of the components included > will be CDI beans. They either need to be defined as singletons, or picked > up via scanning. If singleton is specified, the classes are ignored. > - It ignores classes defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider classes attribute of application when using CDI
[ https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408638#comment-15408638 ] ASF GitHub Bot commented on CXF-6987: - Github user johnament closed the pull request at: https://github.com/apache/cxf/pull/149 > Consider classes attribute of application when using CDI > > > Key: CXF-6987 > URL: https://issues.apache.org/jira/browse/CXF-6987 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > CXF's CDI integration integration assumes that all of the components included > will be CDI beans. They either need to be defined as singletons, or picked > up via scanning. If singleton is specified, the classes are ignored. > - It ignores classes defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider classes attribute of application when using CDI
[ https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408639#comment-15408639 ] ASF GitHub Bot commented on CXF-6987: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/149 I'm going to close and create a new PR to see if that will force jenkins to rebuild. Would it be OK if I modified the job to have a longer history? > Consider classes attribute of application when using CDI > > > Key: CXF-6987 > URL: https://issues.apache.org/jira/browse/CXF-6987 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > CXF's CDI integration integration assumes that all of the components included > will be CDI beans. They either need to be defined as singletons, or picked > up via scanning. If singleton is specified, the classes are ignored. > - It ignores classes defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider classes attribute of application when using CDI
[ https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408642#comment-15408642 ] ASF GitHub Bot commented on CXF-6987: - GitHub user johnament opened a pull request: https://github.com/apache/cxf/pull/153 [CXF-6987] Also consider the classes defined on an application when s… …ingletons are populated. You can merge this pull request into a Git repository by running: $ git pull https://github.com/johnament/cxf CXF-6987 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/153.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 #153 commit a97a7ff004669cf8d4f8264111861a73765631e0 Author: John D. Ament Date: 2016-08-02T23:49:29Z [CXF-6987] Also consider the classes defined on an application when singletons are populated. > Consider classes attribute of application when using CDI > > > Key: CXF-6987 > URL: https://issues.apache.org/jira/browse/CXF-6987 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > CXF's CDI integration integration assumes that all of the components included > will be CDI beans. They either need to be defined as singletons, or picked > up via scanning. If singleton is specified, the classes are ignored. > - It ignores classes defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider classes attribute of application when using CDI
[ https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408645#comment-15408645 ] ASF GitHub Bot commented on CXF-6987: - Github user johnament closed the pull request at: https://github.com/apache/cxf/pull/153 > Consider classes attribute of application when using CDI > > > Key: CXF-6987 > URL: https://issues.apache.org/jira/browse/CXF-6987 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > CXF's CDI integration integration assumes that all of the components included > will be CDI beans. They either need to be defined as singletons, or picked > up via scanning. If singleton is specified, the classes are ignored. > - It ignores classes defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider classes attribute of application when using CDI
[ https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408649#comment-15408649 ] ASF GitHub Bot commented on CXF-6987: - Github user johnament commented on the issue: https://github.com/apache/cxf/pull/149 Oh, you merged it! Heh, thanks. > Consider classes attribute of application when using CDI > > > Key: CXF-6987 > URL: https://issues.apache.org/jira/browse/CXF-6987 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > CXF's CDI integration integration assumes that all of the components included > will be CDI beans. They either need to be defined as singletons, or picked > up via scanning. If singleton is specified, the classes are ignored. > - It ignores classes defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6995) Fix the overlap between ResourceUtils.createApplication and JAXRSCdiResourceExtension beans discovery
Andriy Redko created CXF-6995: - Summary: Fix the overlap between ResourceUtils.createApplication and JAXRSCdiResourceExtension beans discovery Key: CXF-6995 URL: https://issues.apache.org/jira/browse/CXF-6995 Project: CXF Issue Type: Bug Reporter: Andriy Redko Assignee: Andriy Redko Fix For: 3.2.0 There is an overlap between ResourceUtils.createApplication and the work JAXRSCdiResourceExtension is doing for beans discovery. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6987) Consider classes attribute of application when using CDI
[ https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408673#comment-15408673 ] Andriy Redko commented on CXF-6987: --- Yeah, [~johndament], I have merged it, should be fine, CDI test cases pass. For master we do need to fix the overlap between ResourceUtils.createApplication and the work JAXRSCdiResourceExtension is doing. I created this guy to track that: https://issues.apache.org/jira/browse/CXF-6995. Thanks for your help! > Consider classes attribute of application when using CDI > > > Key: CXF-6987 > URL: https://issues.apache.org/jira/browse/CXF-6987 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament > > CXF's CDI integration integration assumes that all of the components included > will be CDI beans. They either need to be defined as singletons, or picked > up via scanning. If singleton is specified, the classes are ignored. > - It ignores classes defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6987) Consider classes attribute of application when using CDI
[ https://issues.apache.org/jira/browse/CXF-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-6987. --- Resolution: Fixed Assignee: Andriy Redko > Consider classes attribute of application when using CDI > > > Key: CXF-6987 > URL: https://issues.apache.org/jira/browse/CXF-6987 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.6 >Reporter: John D. Ament >Assignee: Andriy Redko > > CXF's CDI integration integration assumes that all of the components included > will be CDI beans. They either need to be defined as singletons, or picked > up via scanning. If singleton is specified, the classes are ignored. > - It ignores classes defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6995) Fix the overlap between ResourceUtils.createApplication and JAXRSCdiResourceExtension beans discovery
[ https://issues.apache.org/jira/browse/CXF-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-6995: -- Description: There is an overlap between ResourceUtils.createApplication and the work JAXRSCdiResourceExtension is doing for beans discovery. ResourceUtils.createApplication already populates JAXRSServerFactoryBean instance service beans, providers and features, but JAXRSCdiResourceExtension does the same, from getSingletons(). As the result, there are duplicate entries in the lists. The fix removes getSingletons() but keeps getClasses() only, as those should be instantiated by CDI. (was: There is an overlap between ResourceUtils.createApplication and the work JAXRSCdiResourceExtension is doing for beans discovery.) > Fix the overlap between ResourceUtils.createApplication and > JAXRSCdiResourceExtension beans discovery > - > > Key: CXF-6995 > URL: https://issues.apache.org/jira/browse/CXF-6995 > Project: CXF > Issue Type: Bug >Reporter: Andriy Redko >Assignee: Andriy Redko > Fix For: 3.2.0 > > > There is an overlap between ResourceUtils.createApplication and the work > JAXRSCdiResourceExtension is doing for beans discovery. > ResourceUtils.createApplication already populates JAXRSServerFactoryBean > instance service beans, providers and features, but JAXRSCdiResourceExtension > does the same, from getSingletons(). As the result, there are duplicate > entries in the lists. The fix removes getSingletons() but keeps getClasses() > only, as those should be instantiated by CDI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6995) Fix the overlap between ResourceUtils.createApplication and JAXRSCdiResourceExtension beans discovery
[ https://issues.apache.org/jira/browse/CXF-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-6995. --- Resolution: Fixed > Fix the overlap between ResourceUtils.createApplication and > JAXRSCdiResourceExtension beans discovery > - > > Key: CXF-6995 > URL: https://issues.apache.org/jira/browse/CXF-6995 > Project: CXF > Issue Type: Bug >Reporter: Andriy Redko >Assignee: Andriy Redko > Fix For: 3.2.0 > > > There is an overlap between ResourceUtils.createApplication and the work > JAXRSCdiResourceExtension is doing for beans discovery. > ResourceUtils.createApplication already populates JAXRSServerFactoryBean > instance service beans, providers and features, but JAXRSCdiResourceExtension > does the same, from getSingletons(). As the result, there are duplicate > entries in the lists. The fix removes getSingletons() but keeps getClasses() > only, as those should be instantiated by CDI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6996) "n" in JWK for RSA should be unsigned, but is signed in JwkUtils.prepareRSAJwk
Svein Otto Solem created CXF-6996: - Summary: "n" in JWK for RSA should be unsigned, but is signed in JwkUtils.prepareRSAJwk Key: CXF-6996 URL: https://issues.apache.org/jira/browse/CXF-6996 Project: CXF Issue Type: Bug Components: JAX-RS Security Affects Versions: 3.1.7 Reporter: Svein Otto Solem Priority: Minor The length of the "n" value is 257 bytes for a 2048 bits key length. If "n" is handled as an unsigned int, it should be at most 256 bytes. The added null byte is caused by BigInteger.toByteArray() which always handles the integer as a signed integer. A fix is just to remove all the first 0-bytes in the encodedModulus, see JwkUtils.prepareRSAJwk. This fix will surely break clients which just decodes the "n" as an unsigned value using new BigInteger(byte[]) . These clients must be changed to either always insert a leading "0-byte" before using the new BigInteger(byte[]) contstructor, or they should use the BigInteger(signum, magnitude) constructor. The extra "sign byte" is mentioned in: https://tools.ietf.org/html/rfc7518#page-30 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
