[jira] [Commented] (CXF-7130) Maven plugin to invoke SOAP service
[ https://issues.apache.org/jira/browse/CXF-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15669877#comment-15669877 ] ASF GitHub Bot commented on CXF-7130: - Github user zregvart closed the pull request at: https://github.com/apache/cxf/pull/193 > Maven plugin to invoke SOAP service > --- > > Key: CXF-7130 > URL: https://issues.apache.org/jira/browse/CXF-7130 > Project: CXF > Issue Type: Improvement > Components: Tooling >Affects Versions: 3.2.0 > Environment: Any >Reporter: Zoran Regvart >Assignee: Freeman Fang >Priority: Minor > > I needed a Maven plugin that would allow me to invoke SOAP service as a part > of Maven lifecycle so I implemented one, and I'm hoping that you can include > it in CXF. > The plugin has the functionality of calling SOAP service given a WSDL, port, > service, operation, request body and optional SOAP headers. Additionally > Maven project properties can be set from the response using XPath expressions > and additional XPath expression can be used to determine if the request needs > to be repeated. > This is a minimal implementation that I needed for my use-case, hope you find > it useful and that it can be incorporated in CXF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7130) Maven plugin to invoke SOAP service
[ https://issues.apache.org/jira/browse/CXF-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15669876#comment-15669876 ] ASF GitHub Bot commented on CXF-7130: - Github user zregvart commented on the issue: https://github.com/apache/cxf/pull/193 Had a discussion with @ffang and decided that this was not a good fit for CXF. Thanks for the consideration! > Maven plugin to invoke SOAP service > --- > > Key: CXF-7130 > URL: https://issues.apache.org/jira/browse/CXF-7130 > Project: CXF > Issue Type: Improvement > Components: Tooling >Affects Versions: 3.2.0 > Environment: Any >Reporter: Zoran Regvart >Assignee: Freeman Fang >Priority: Minor > > I needed a Maven plugin that would allow me to invoke SOAP service as a part > of Maven lifecycle so I implemented one, and I'm hoping that you can include > it in CXF. > The plugin has the functionality of calling SOAP service given a WSDL, port, > service, operation, request body and optional SOAP headers. Additionally > Maven project properties can be set from the response using XPath expressions > and additional XPath expression can be used to determine if the request needs > to be repeated. > This is a minimal implementation that I needed for my use-case, hope you find > it useful and that it can be incorporated in CXF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6590) MAPCodec: memory leak with sync client when soapfaults returned from endpoint
[ https://issues.apache.org/jira/browse/CXF-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15669918#comment-15669918 ] Bjørn Hilstad commented on CXF-6590: I reopened this issue some time ago but I am not sure it has been picked up. [~dkulp]: Will this be fixed or should I create a new case? > MAPCodec: memory leak with sync client when soapfaults returned from endpoint > - > > Key: CXF-6590 > URL: https://issues.apache.org/jira/browse/CXF-6590 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.0.6 > Environment: CXF 3.0.6, JDK 1.7, CXF 3.1.2 >Reporter: Bjørn Hilstad >Assignee: Daniel Kulp > Fix For: 3.1.3, 3.0.7 > > Attachments: cxfoom.zip, wiremock.zip > > > This bug is similar to CXF-2591 but relates to sync clients. > A simple client using a service with WS-Addressing which makes repeated calls > to a service that returns a soapfault will cause a build up of objects in > MAPCodec::uncorrelatedExchanges. > The real use case is an application using Apache Camel to keep invoking a > service that returns a fault (for instance wsa:DestinationUnreachable) using > the built in redelivery-functions of Apache Camel. > A simple CXF client that reproduces the issue has been created. The client > just invokes a service in a loop and by observing the used memory (jconsole) > and performing memory dumps which can be analyzed using MAT, you can see the > issue. > A standalone wiremock functions as the endpoint. > The reproducers will be attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CXF-7130) Maven plugin to invoke SOAP service
[ https://issues.apache.org/jira/browse/CXF-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoran Regvart closed CXF-7130. -- Resolution: Won't Fix > Maven plugin to invoke SOAP service > --- > > Key: CXF-7130 > URL: https://issues.apache.org/jira/browse/CXF-7130 > Project: CXF > Issue Type: Improvement > Components: Tooling >Affects Versions: 3.2.0 > Environment: Any >Reporter: Zoran Regvart >Assignee: Freeman Fang >Priority: Minor > > I needed a Maven plugin that would allow me to invoke SOAP service as a part > of Maven lifecycle so I implemented one, and I'm hoping that you can include > it in CXF. > The plugin has the functionality of calling SOAP service given a WSDL, port, > service, operation, request body and optional SOAP headers. Additionally > Maven project properties can be set from the response using XPath expressions > and additional XPath expression can be used to determine if the request needs > to be repeated. > This is a minimal implementation that I needed for my use-case, hope you find > it useful and that it can be incorporated in CXF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7135) ConcurrentModificationException
Dan Salt created CXF-7135: - Summary: ConcurrentModificationException Key: CXF-7135 URL: https://issues.apache.org/jira/browse/CXF-7135 Project: CXF Issue Type: Bug Components: JMS Affects Versions: 3.0.11 Environment: Mac OSX 10.11.6. Java JDK 1.8.0_71 (64 bit Server) Reporter: Dan Salt Attachments: cxf-rsjms-testcase.zip Our platform allows the user to switch transports for a particular proxy based on configuration. We currently allow HTTP and JMS as possible options. During recent performance testing, we've hit a bug which causes JAXRS Clients over JMS to fail with a ConcurrentModificationException: A test case is attached that reproduces our problem. Our test executes requests across multiple concurrent threads, switching between JMS and HTTP for both JAXWS and JAXRS Client Proxies. In the test case, executing JAXWS over JMS works fine, both in single and multi-threaded tests. JAXRS works fine across single and multi-threaded tests over HTTP with the 'ThreadSafe' flag set on the Client Factory. But when the transport is switched to JMS two problems occur: 1) The ConnectionFactoryFeature fails to properly set the JMS Conduit and results in an error because no Connection Factory is set. This is because in JAXRS Clients, the InterceptorProvider is neither a Client or Server, it is a ClientConfiguration, so the JMS ConnectionFactoryFeature does not fire either of it's methods. We have worked around this in our code by sub-classing and overriding the method: public void initialize(InterceptorProvider interceptorProvider, Bus bus) .. and adding code similar to that in the ConnectionFactory feature. This resolves the missing ConnectionFactory problem. 2) Under multi-threaded conditions, the JAXRS Clients fail with the following exception: javax.ws.rs.client.ResponseProcessingException: Problem with reading the data, class java.lang.String, ContentType: text/plain. at org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:438) at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:378) at org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:521) at org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:817) at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:760) at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228) at com.sun.proxy.$Proxy24.doSimpleMethod(Unknown Source) at com.ge.testcase.ThreadingTest$ThreadedRSJMSTest.run(ThreadingTest.java:132) at java.lang.Thread.run(Thread.java:745) Caused by: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) at java.util.HashMap$EntryIterator.next(HashMap.java:1463) at java.util.HashMap$EntryIterator.next(HashMap.java:1461) at java.util.HashMap.putMapEntries(HashMap.java:511) at java.util.HashMap.putAll(HashMap.java:784) at org.apache.cxf.message.MessageImpl$1.putAll(MessageImpl.java:188) at org.apache.cxf.message.MessageImpl.calcContextCache(MessageImpl.java:213) at org.apache.cxf.message.MessageImpl.getContextualProperty(MessageImpl.java:174) at org.apache.cxf.jaxrs.impl.HttpHeadersImpl.getRequestHeaders(HttpHeadersImpl.java:172) at org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1345) at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:369) ... 7 more This occurs even though the 'ThreadSafe' property is set via: rsClientFactory.setThreadSafe(true); I've done quite a large amount of digging through the code to try and narrow down the scope of the problem, and the results above is as far as I could get, unfortunately. Finally, one important factor is that this error only happens on the latest 3.0.x release (3.0.11). When I switch my test case to 3.1.8, it does NOT occur. Not sure if this equates to a fix not being back-ported, or a fundamental difference in functionality. Sadly, we're not able to yet move to 3.1.x, because of running inside the Karaf container, and our dependencies on Camel and Spring 3.x. Thanks. Please let me know if you need any other information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-7135) ConcurrentModificationException
[ https://issues.apache.org/jira/browse/CXF-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Salt updated CXF-7135: -- Attachment: cxf-rsjms-testcase.zip Test case for this issue > ConcurrentModificationException > > > Key: CXF-7135 > URL: https://issues.apache.org/jira/browse/CXF-7135 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.0.11 > Environment: Mac OSX 10.11.6. > Java JDK 1.8.0_71 (64 bit Server) >Reporter: Dan Salt > Attachments: cxf-rsjms-testcase.zip > > > Our platform allows the user to switch transports for a particular proxy > based on configuration. We currently allow HTTP and JMS as possible options. > During recent performance testing, we've hit a bug which causes JAXRS Clients > over JMS to fail with a ConcurrentModificationException: > A test case is attached that reproduces our problem. > Our test executes requests across multiple concurrent threads, switching > between JMS and HTTP for both JAXWS and JAXRS Client Proxies. In the test > case, executing JAXWS over JMS works fine, both in single and multi-threaded > tests. JAXRS works fine across single and multi-threaded tests over HTTP with > the 'ThreadSafe' flag set on the Client Factory. But when the transport is > switched to JMS two problems occur: > 1) The ConnectionFactoryFeature fails to properly set the JMS Conduit and > results in an error because no Connection Factory is set. This is because in > JAXRS Clients, the InterceptorProvider is neither a Client or Server, it is a > ClientConfiguration, so the JMS ConnectionFactoryFeature does not fire either > of it's methods. > We have worked around this in our code by sub-classing and overriding the > method: > public void initialize(InterceptorProvider interceptorProvider, Bus bus) > .. and adding code similar to that in the ConnectionFactory feature. This > resolves the missing ConnectionFactory problem. > 2) Under multi-threaded conditions, the JAXRS Clients fail with the following > exception: > javax.ws.rs.client.ResponseProcessingException: Problem with reading the > data, class java.lang.String, ContentType: text/plain. > at > org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:438) > at > org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:378) > at > org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:521) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:817) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:760) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228) > at com.sun.proxy.$Proxy24.doSimpleMethod(Unknown Source) > at > com.ge.testcase.ThreadingTest$ThreadedRSJMSTest.run(ThreadingTest.java:132) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.util.ConcurrentModificationException > at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) > at java.util.HashMap$EntryIterator.next(HashMap.java:1463) > at java.util.HashMap$EntryIterator.next(HashMap.java:1461) > at java.util.HashMap.putMapEntries(HashMap.java:511) > at java.util.HashMap.putAll(HashMap.java:784) > at org.apache.cxf.message.MessageImpl$1.putAll(MessageImpl.java:188) > at > org.apache.cxf.message.MessageImpl.calcContextCache(MessageImpl.java:213) > at > org.apache.cxf.message.MessageImpl.getContextualProperty(MessageImpl.java:174) > at > org.apache.cxf.jaxrs.impl.HttpHeadersImpl.getRequestHeaders(HttpHeadersImpl.java:172) > at > org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1345) > at > org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:369) > ... 7 more > This occurs even though the 'ThreadSafe' property is set via: > rsClientFactory.setThreadSafe(true); > I've done quite a large amount of digging through the code to try and narrow > down the scope of the problem, and the results above is as far as I could > get, unfortunately. > Finally, one important factor is that this error only happens on the latest > 3.0.x release (3.0.11). When I switch my test case to 3.1.8, it does NOT > occur. Not sure if this equates to a fix not being back-ported, or a > fundamental difference in functionality. Sadly, we're not able to yet move to > 3.1.x, because of running inside the Karaf container, and our dependencies on > Camel and Spring 3.x. > Thanks. Please let me know if you need any other information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7136) soapfault mixed with response
David J. M. Karlsen created CXF-7136:
Summary: soapfault mixed with response
Key: CXF-7136
URL: https://issues.apache.org/jira/browse/CXF-7136
Project: CXF
Issue Type: Bug
Components: JAXB Databinding
Affects Versions: 3.1.7
Environment: RHEL Linux, kern 3.10.0-229.1.2.el7.x86_64
java -version
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
Reporter: David J. M. Karlsen
we get this fault due to invalid chars attempted to being marshalled (which is
obviosly a problem at our shoulders, but - what I see as the bug - is that the
Fault XML is intermixed with the response streaming - hence the client is not
able to parse the fault as the sudden appering of a soap:fault element inside
the expected response payload is not expected:
application log:
{noformat}
has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Invalid white space character (0x1) in text
to output (in xml 1.1, could output as a character entity)
at
org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(AbstractOutDatabindingInterceptor.java:154)
at
org.apache.cxf.wsdl.interceptors.BareOutInterceptor.handleMessage(BareOutInterceptor.java:68)
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:299)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:218)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:274)
at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1689)
{noformat}
from the payload log (using the ext-logger "modern" payload logging mechanism:
{noformat}
.FAULT_OUT - http://schemas.xmlsoap.org/soap/envelope/";>……
soap:ServerInvalid
white space character (0x1) in text to output (in xml 1.1, could output as a
character
entity)
{noformat}
Notice: we have the element (which is the element causing the
illegal char) - and then the fault follows - and then the rest of the element!
What I'd rather expect is that the service raised an fault - and not any of the
contents.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7135) ConcurrentModificationException
[ https://issues.apache.org/jira/browse/CXF-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Salt updated CXF-7135: -- Description: Our platform allows the user to switch transports for a particular proxy based on configuration. We currently allow HTTP and JMS as possible options. During recent performance testing, we've hit a bug which causes JAXRS Clients over JMS to fail with a ConcurrentModificationException: A test case is attached that reproduces our problem. Our test executes requests across multiple concurrent threads, switching between JMS and HTTP for both JAXWS and JAXRS Client Proxies. In the test case, executing JAXWS over JMS works fine, both in single and multi-threaded tests. JAXRS works fine across single and multi-threaded tests over HTTP with the 'ThreadSafe' flag set on the Client Factory. But when the transport is switched to JMS two problems occur: 1) The ConnectionFactoryFeature fails to properly set the JMS Connection Factory on the Conduit and results in an error at send-time because no Connection Factory is set. This is because in JAXRS Clients, the InterceptorProvider is neither a Client or Server, it is a ClientConfiguration, so the JMS ConnectionFactoryFeature does not fire either of it's methods: public void initialize(Client client, Bus bus) public void initialize(Server server, Bus bus) We have worked around this in our code by sub-classing and overriding the method: public void initialize(InterceptorProvider interceptorProvider, Bus bus) .. and adding code similar to that in the ConnectionFactory feature. This resolves the missing ConnectionFactory problem. 2) Under multi-threaded conditions, the JAXRS Clients fail with the following exception: javax.ws.rs.client.ResponseProcessingException: Problem with reading the data, class java.lang.String, ContentType: text/plain. at org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:438) at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:378) at org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:521) at org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:817) at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:760) at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228) at com.sun.proxy.$Proxy24.doSimpleMethod(Unknown Source) at com.ge.testcase.ThreadingTest$ThreadedRSJMSTest.run(ThreadingTest.java:132) at java.lang.Thread.run(Thread.java:745) Caused by: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) at java.util.HashMap$EntryIterator.next(HashMap.java:1463) at java.util.HashMap$EntryIterator.next(HashMap.java:1461) at java.util.HashMap.putMapEntries(HashMap.java:511) at java.util.HashMap.putAll(HashMap.java:784) at org.apache.cxf.message.MessageImpl$1.putAll(MessageImpl.java:188) at org.apache.cxf.message.MessageImpl.calcContextCache(MessageImpl.java:213) at org.apache.cxf.message.MessageImpl.getContextualProperty(MessageImpl.java:174) at org.apache.cxf.jaxrs.impl.HttpHeadersImpl.getRequestHeaders(HttpHeadersImpl.java:172) at org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1345) at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:369) ... 7 more This occurs even though the 'ThreadSafe' property is set via: rsClientFactory.setThreadSafe(true); I've done quite a large amount of digging through the code to try and narrow down the scope of the problem, and the results above is as far as I could get, unfortunately. Finally, one important factor is that this error only happens on the latest 3.0.x release (3.0.11). When I switch my test case to 3.1.8, it does NOT occur. Not sure if this equates to a fix not being back-ported, or a fundamental difference in functionality. Sadly, we're not able to yet move to 3.1.x, because of running inside the Karaf container, and our dependencies on Camel and Spring 3.x. Thanks. Please let me know if you need any other information. was: Our platform allows the user to switch transports for a particular proxy based on configuration. We currently allow HTTP and JMS as possible options. During recent performance testing, we've hit a bug which causes JAXRS Clients over JMS to fail with a ConcurrentModificationException: A test case is attached that reproduces our problem. Our test executes requests across multiple concurrent threads, switching between JMS and HTTP for both JAXWS and JAXRS Client Proxies. In the test case, executing JAXWS over JMS works fine, both in single and multi-threaded tests. JAXRS works fine across single and multi-threaded tes
[jira] [Commented] (CXF-7015) Invalid URL encoding causes error 500
[
https://issues.apache.org/jira/browse/CXF-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670500#comment-15670500
]
ASF GitHub Bot commented on CXF-7015:
-
Github user asfgit closed the pull request at:
https://github.com/apache/cxf/pull/196
> Invalid URL encoding causes error 500
> -
>
> Key: CXF-7015
> URL: https://issues.apache.org/jira/browse/CXF-7015
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.4
>Reporter: Sanjay Patel
>
> When using Apache CXF JAX RS Client 3.0.3
> We would get a 400 Response with URLDecoder: Incomplete trailing escape (%)
> pattern.
> Using Apache CXF JAX RS Client 3.0.4 and above we see the below issue.
> If we make a request using JAX RS to Spring with an invalid URL encoding,
> such as %3, we are getting a 500 Response, and an BufferUnderflowException.
> As seen below.
> {code}
> java.nio.BufferUnderflowException at
> java.nio.Buffer.nextGetIndex(Buffer.java:500) at
> java.nio.HeapByteBuffer.get(HeapByteBuffer.java:135) at
> org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:96) at
> org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:67) at
> org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:122) at
> org.apache.cxf.jaxrs.utils.HttpUtils.urlDecode(HttpUtils.java:97) at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1262)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1236)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:115)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:109)
> at
> org.apache.cxf.jaxrs.impl.RequestPreprocessor.preprocess(RequestPreprocessor.java:74)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:102)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> 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:622) at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:528)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1099)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1520)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1476)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[jira] [Resolved] (CXF-7015) Invalid URL encoding causes error 500
[
https://issues.apache.org/jira/browse/CXF-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-7015.
---
Resolution: Fixed
Assignee: Sergey Beryozkin
Fix Version/s: 3.0.12
3.1.9
3.2.0
Thanks for the patch
> Invalid URL encoding causes error 500
> -
>
> Key: CXF-7015
> URL: https://issues.apache.org/jira/browse/CXF-7015
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.4
>Reporter: Sanjay Patel
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.9, 3.0.12
>
>
> When using Apache CXF JAX RS Client 3.0.3
> We would get a 400 Response with URLDecoder: Incomplete trailing escape (%)
> pattern.
> Using Apache CXF JAX RS Client 3.0.4 and above we see the below issue.
> If we make a request using JAX RS to Spring with an invalid URL encoding,
> such as %3, we are getting a 500 Response, and an BufferUnderflowException.
> As seen below.
> {code}
> java.nio.BufferUnderflowException at
> java.nio.Buffer.nextGetIndex(Buffer.java:500) at
> java.nio.HeapByteBuffer.get(HeapByteBuffer.java:135) at
> org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:96) at
> org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:67) at
> org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:122) at
> org.apache.cxf.jaxrs.utils.HttpUtils.urlDecode(HttpUtils.java:97) at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1262)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1236)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:115)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:109)
> at
> org.apache.cxf.jaxrs.impl.RequestPreprocessor.preprocess(RequestPreprocessor.java:74)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:102)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> 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:622) at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:273)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:528)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1099)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1520)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1476)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor
[jira] [Updated] (CXF-7135) ConcurrentModificationException in MessageImpl.calcContextCache() when using JMS Transport and JAXRS Client
[ https://issues.apache.org/jira/browse/CXF-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Salt updated CXF-7135: -- Summary: ConcurrentModificationException in MessageImpl.calcContextCache() when using JMS Transport and JAXRS Client (was: ConcurrentModificationException in MessageImpl.calcContextCache() when using JMS Transport) > ConcurrentModificationException in MessageImpl.calcContextCache() when using > JMS Transport and JAXRS Client > --- > > Key: CXF-7135 > URL: https://issues.apache.org/jira/browse/CXF-7135 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.0.11 > Environment: Mac OSX 10.11.6. > Java JDK 1.8.0_71 (64 bit Server) >Reporter: Dan Salt > Attachments: cxf-rsjms-testcase.zip > > > Our platform allows the user to switch transports for a particular proxy > based on configuration. We currently allow HTTP and JMS as possible options. > During recent performance testing, we've hit a bug which causes JAXRS Clients > over JMS to fail with a ConcurrentModificationException: > A test case is attached that reproduces our problem. > Our test executes requests across multiple concurrent threads, switching > between JMS and HTTP for both JAXWS and JAXRS Client Proxies. In the test > case, executing JAXWS over JMS works fine, both in single and multi-threaded > tests. JAXRS works fine across single and multi-threaded tests over HTTP with > the 'ThreadSafe' flag set on the Client Factory. But when the transport is > switched to JMS two problems occur: > 1) The ConnectionFactoryFeature fails to properly set the JMS Connection > Factory on the Conduit and results in an error at send-time because no > Connection Factory is set. This is because in JAXRS Clients, the > InterceptorProvider is neither a Client or Server, it is a > ClientConfiguration, so the JMS ConnectionFactoryFeature does not fire either > of it's methods: > public void initialize(Client client, Bus bus) > public void initialize(Server server, Bus bus) > We have worked around this in our code by sub-classing and overriding the > method: > public void initialize(InterceptorProvider interceptorProvider, Bus bus) > .. and adding code similar to that in the ConnectionFactory feature. This > resolves the missing ConnectionFactory problem. > 2) Under multi-threaded conditions, the JAXRS Clients fail with the following > exception: > javax.ws.rs.client.ResponseProcessingException: Problem with reading the > data, class java.lang.String, ContentType: text/plain. > at > org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:438) > at > org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:378) > at > org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:521) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:817) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:760) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228) > at com.sun.proxy.$Proxy24.doSimpleMethod(Unknown Source) > at > com.ge.testcase.ThreadingTest$ThreadedRSJMSTest.run(ThreadingTest.java:132) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.util.ConcurrentModificationException > at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) > at java.util.HashMap$EntryIterator.next(HashMap.java:1463) > at java.util.HashMap$EntryIterator.next(HashMap.java:1461) > at java.util.HashMap.putMapEntries(HashMap.java:511) > at java.util.HashMap.putAll(HashMap.java:784) > at org.apache.cxf.message.MessageImpl$1.putAll(MessageImpl.java:188) > at > org.apache.cxf.message.MessageImpl.calcContextCache(MessageImpl.java:213) > at > org.apache.cxf.message.MessageImpl.getContextualProperty(MessageImpl.java:174) > at > org.apache.cxf.jaxrs.impl.HttpHeadersImpl.getRequestHeaders(HttpHeadersImpl.java:172) > at > org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1345) > at > org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:369) > ... 7 more > This occurs even though the 'ThreadSafe' property is set via: > rsClientFactory.setThreadSafe(true); > I've done quite a large amount of digging through the code to try and narrow > down the scope of the problem, and the results above is as far as I could > get, unfortunately. > Finally, one important factor is that this error only happens on the latest > 3.0.x release (3.0.11). When I switch my test case to 3.1.8, it does NOT > occur. Not sure if this equates to a fix not being back-ported
[jira] [Updated] (CXF-7135) ConcurrentModificationException in MessageImpl.calcContextCache() when using JMS Transport
[ https://issues.apache.org/jira/browse/CXF-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Salt updated CXF-7135: -- Summary: ConcurrentModificationException in MessageImpl.calcContextCache() when using JMS Transport (was: ConcurrentModificationException ) > ConcurrentModificationException in MessageImpl.calcContextCache() when using > JMS Transport > -- > > Key: CXF-7135 > URL: https://issues.apache.org/jira/browse/CXF-7135 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.0.11 > Environment: Mac OSX 10.11.6. > Java JDK 1.8.0_71 (64 bit Server) >Reporter: Dan Salt > Attachments: cxf-rsjms-testcase.zip > > > Our platform allows the user to switch transports for a particular proxy > based on configuration. We currently allow HTTP and JMS as possible options. > During recent performance testing, we've hit a bug which causes JAXRS Clients > over JMS to fail with a ConcurrentModificationException: > A test case is attached that reproduces our problem. > Our test executes requests across multiple concurrent threads, switching > between JMS and HTTP for both JAXWS and JAXRS Client Proxies. In the test > case, executing JAXWS over JMS works fine, both in single and multi-threaded > tests. JAXRS works fine across single and multi-threaded tests over HTTP with > the 'ThreadSafe' flag set on the Client Factory. But when the transport is > switched to JMS two problems occur: > 1) The ConnectionFactoryFeature fails to properly set the JMS Connection > Factory on the Conduit and results in an error at send-time because no > Connection Factory is set. This is because in JAXRS Clients, the > InterceptorProvider is neither a Client or Server, it is a > ClientConfiguration, so the JMS ConnectionFactoryFeature does not fire either > of it's methods: > public void initialize(Client client, Bus bus) > public void initialize(Server server, Bus bus) > We have worked around this in our code by sub-classing and overriding the > method: > public void initialize(InterceptorProvider interceptorProvider, Bus bus) > .. and adding code similar to that in the ConnectionFactory feature. This > resolves the missing ConnectionFactory problem. > 2) Under multi-threaded conditions, the JAXRS Clients fail with the following > exception: > javax.ws.rs.client.ResponseProcessingException: Problem with reading the > data, class java.lang.String, ContentType: text/plain. > at > org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:438) > at > org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:378) > at > org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:521) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:817) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:760) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228) > at com.sun.proxy.$Proxy24.doSimpleMethod(Unknown Source) > at > com.ge.testcase.ThreadingTest$ThreadedRSJMSTest.run(ThreadingTest.java:132) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.util.ConcurrentModificationException > at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) > at java.util.HashMap$EntryIterator.next(HashMap.java:1463) > at java.util.HashMap$EntryIterator.next(HashMap.java:1461) > at java.util.HashMap.putMapEntries(HashMap.java:511) > at java.util.HashMap.putAll(HashMap.java:784) > at org.apache.cxf.message.MessageImpl$1.putAll(MessageImpl.java:188) > at > org.apache.cxf.message.MessageImpl.calcContextCache(MessageImpl.java:213) > at > org.apache.cxf.message.MessageImpl.getContextualProperty(MessageImpl.java:174) > at > org.apache.cxf.jaxrs.impl.HttpHeadersImpl.getRequestHeaders(HttpHeadersImpl.java:172) > at > org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1345) > at > org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:369) > ... 7 more > This occurs even though the 'ThreadSafe' property is set via: > rsClientFactory.setThreadSafe(true); > I've done quite a large amount of digging through the code to try and narrow > down the scope of the problem, and the results above is as far as I could > get, unfortunately. > Finally, one important factor is that this error only happens on the latest > 3.0.x release (3.0.11). When I switch my test case to 3.1.8, it does NOT > occur. Not sure if this equates to a fix not being back-ported, or a > fundamental difference in functionality. Sadly, we're not able to yet move to > 3.1.x, because of ru
[jira] [Updated] (CXF-7135) ConcurrentModificationException in MessageImpl.calcContextCache() when using JMS Transport and JAXRS Client
[ https://issues.apache.org/jira/browse/CXF-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Salt updated CXF-7135: -- Component/s: JAX-RS > ConcurrentModificationException in MessageImpl.calcContextCache() when using > JMS Transport and JAXRS Client > --- > > Key: CXF-7135 > URL: https://issues.apache.org/jira/browse/CXF-7135 > Project: CXF > Issue Type: Bug > Components: JAX-RS, JMS >Affects Versions: 3.0.11 > Environment: Mac OSX 10.11.6. > Java JDK 1.8.0_71 (64 bit Server) >Reporter: Dan Salt > Attachments: cxf-rsjms-testcase.zip > > > Our platform allows the user to switch transports for a particular proxy > based on configuration. We currently allow HTTP and JMS as possible options. > During recent performance testing, we've hit a bug which causes JAXRS Clients > over JMS to fail with a ConcurrentModificationException: > A test case is attached that reproduces our problem. > Our test executes requests across multiple concurrent threads, switching > between JMS and HTTP for both JAXWS and JAXRS Client Proxies. In the test > case, executing JAXWS over JMS works fine, both in single and multi-threaded > tests. JAXRS works fine across single and multi-threaded tests over HTTP with > the 'ThreadSafe' flag set on the Client Factory. But when the transport is > switched to JMS two problems occur: > 1) The ConnectionFactoryFeature fails to properly set the JMS Connection > Factory on the Conduit and results in an error at send-time because no > Connection Factory is set. This is because in JAXRS Clients, the > InterceptorProvider is neither a Client or Server, it is a > ClientConfiguration, so the JMS ConnectionFactoryFeature does not fire either > of it's methods: > public void initialize(Client client, Bus bus) > public void initialize(Server server, Bus bus) > We have worked around this in our code by sub-classing and overriding the > method: > public void initialize(InterceptorProvider interceptorProvider, Bus bus) > .. and adding code similar to that in the ConnectionFactory feature. This > resolves the missing ConnectionFactory problem. > 2) Under multi-threaded conditions, the JAXRS Clients fail with the following > exception: > javax.ws.rs.client.ResponseProcessingException: Problem with reading the > data, class java.lang.String, ContentType: text/plain. > at > org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:438) > at > org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:378) > at > org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:521) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:817) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:760) > at > org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228) > at com.sun.proxy.$Proxy24.doSimpleMethod(Unknown Source) > at > com.ge.testcase.ThreadingTest$ThreadedRSJMSTest.run(ThreadingTest.java:132) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.util.ConcurrentModificationException > at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) > at java.util.HashMap$EntryIterator.next(HashMap.java:1463) > at java.util.HashMap$EntryIterator.next(HashMap.java:1461) > at java.util.HashMap.putMapEntries(HashMap.java:511) > at java.util.HashMap.putAll(HashMap.java:784) > at org.apache.cxf.message.MessageImpl$1.putAll(MessageImpl.java:188) > at > org.apache.cxf.message.MessageImpl.calcContextCache(MessageImpl.java:213) > at > org.apache.cxf.message.MessageImpl.getContextualProperty(MessageImpl.java:174) > at > org.apache.cxf.jaxrs.impl.HttpHeadersImpl.getRequestHeaders(HttpHeadersImpl.java:172) > at > org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1345) > at > org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:369) > ... 7 more > This occurs even though the 'ThreadSafe' property is set via: > rsClientFactory.setThreadSafe(true); > I've done quite a large amount of digging through the code to try and narrow > down the scope of the problem, and the results above is as far as I could > get, unfortunately. > Finally, one important factor is that this error only happens on the latest > 3.0.x release (3.0.11). When I switch my test case to 3.1.8, it does NOT > occur. Not sure if this equates to a fix not being back-ported, or a > fundamental difference in functionality. Sadly, we're not able to yet move to > 3.1.x, because of running inside the Karaf container, and our dependencies on > Camel and Spring 3.
[jira] [Updated] (CXF-7135) ConcurrentModificationException in MessageImpl.calcContextCache() when using JMS Transport and JAXRS Client
[ https://issues.apache.org/jira/browse/CXF-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Salt updated CXF-7135: -- Description: Our platform allows the user to switch transports for a particular proxy based on configuration. We currently allow HTTP and JMS as possible options. During recent performance testing, we've hit a bug which causes JAXRS Clients over JMS to fail with a ConcurrentModificationException: A test case is attached that reproduces our problem. Our test executes requests across multiple concurrent threads, switching between JMS and HTTP for both JAXWS and JAXRS Client Proxies. In the test case: - JAXWS over both HTTP and JMS works fine, both in single and multi-threaded tests. - JAXRS works fine across single and multi-threaded tests over HTTP with the 'ThreadSafe' flag set on the Client Factory. - JAXRS over JMS fails. Two problems occur: 1) The ConnectionFactoryFeature fails to properly set the JMS Connection Factory on the Conduit and results in an error at send-time because no Connection Factory is set. This is because in JAXRS Clients, the InterceptorProvider is neither a Client or Server, it is a ClientConfiguration, so the JMS ConnectionFactoryFeature does not fire either of it's methods: public void initialize(Client client, Bus bus) public void initialize(Server server, Bus bus) We have worked around this in our code by sub-classing and overriding the method: public void initialize(InterceptorProvider interceptorProvider, Bus bus) .. and adding code similar to that in the ConnectionFactory feature. This resolves the missing ConnectionFactory problem. 2) Under multi-threaded conditions, the JAXRS Clients fail with the following exception: javax.ws.rs.client.ResponseProcessingException: Problem with reading the data, class java.lang.String, ContentType: text/plain. at org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:438) at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:378) at org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:521) at org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:817) at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:760) at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228) at com.sun.proxy.$Proxy24.doSimpleMethod(Unknown Source) at com.ge.testcase.ThreadingTest$ThreadedRSJMSTest.run(ThreadingTest.java:132) at java.lang.Thread.run(Thread.java:745) Caused by: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) at java.util.HashMap$EntryIterator.next(HashMap.java:1463) at java.util.HashMap$EntryIterator.next(HashMap.java:1461) at java.util.HashMap.putMapEntries(HashMap.java:511) at java.util.HashMap.putAll(HashMap.java:784) at org.apache.cxf.message.MessageImpl$1.putAll(MessageImpl.java:188) at org.apache.cxf.message.MessageImpl.calcContextCache(MessageImpl.java:213) at org.apache.cxf.message.MessageImpl.getContextualProperty(MessageImpl.java:174) at org.apache.cxf.jaxrs.impl.HttpHeadersImpl.getRequestHeaders(HttpHeadersImpl.java:172) at org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1345) at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:369) ... 7 more This occurs even though the 'ThreadSafe' property is set via: rsClientFactory.setThreadSafe(true); I've done quite a large amount of digging through the code to try and narrow down the scope of the problem, and the results above is as far as I could get, unfortunately. Finally, one important factor is that this error only happens on the latest 3.0.x release (3.0.11). When I switch my test case to 3.1.8, it does NOT occur. Not sure if this equates to a fix not being back-ported, or a fundamental difference in functionality. Sadly, we're not able to yet move to 3.1.x, because of running inside the Karaf container, and our dependencies on Camel and Spring 3.x. Thanks. Please let me know if you need any other information. was: Our platform allows the user to switch transports for a particular proxy based on configuration. We currently allow HTTP and JMS as possible options. During recent performance testing, we've hit a bug which causes JAXRS Clients over JMS to fail with a ConcurrentModificationException: A test case is attached that reproduces our problem. Our test executes requests across multiple concurrent threads, switching between JMS and HTTP for both JAXWS and JAXRS Client Proxies. In the test case, executing JAXWS over JMS works fine, both in single and multi-threaded tests. JAXRS works fine across single and multi-threaded tests over HT
[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=15670535#comment-15670535 ] Sergey Beryozkin commented on CXF-7000: --- Hi, https://issues.apache.org/jira/browse/CXF-7047 > 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 >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.8 > > > 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] [Updated] (CXF-7135) ConcurrentModificationException in MessageImpl.calcContextCache() when using JMS Transport and JAXRS Client
[ https://issues.apache.org/jira/browse/CXF-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Salt updated CXF-7135: -- Description: Our platform allows the user to switch transports for a particular proxy based on configuration. We currently allow HTTP and JMS as possible options. During recent performance testing, we've hit a bug which causes JAXRS Clients over JMS to fail with a ConcurrentModificationException: A test case is attached that reproduces our problem. Our test executes requests across multiple concurrent threads, switching between JMS and HTTP for both JAXWS and JAXRS Client Proxies. In the test case: - JAXWS over both HTTP and JMS works fine, both in single and multi-threaded tests. - JAXRS works fine across single and multi-threaded tests over HTTP with the 'ThreadSafe' flag set on the Client Factory. - JAXRS over JMS fails. Two problems occur: 1) The ConnectionFactoryFeature fails to properly set the JMS Connection Factory on the Conduit and results in an error at send-time because no Connection Factory is set. This is because in JAXRS Clients, the InterceptorProvider is neither a Client or Server, it is a ClientConfiguration, so the JMS ConnectionFactoryFeature does not fire either of it's methods: public void initialize(Client client, Bus bus) public void initialize(Server server, Bus bus) We have worked around this in our code by sub-classing and overriding the method: public void initialize(InterceptorProvider interceptorProvider, Bus bus) .. and adding code similar to that in the ConnectionFactory feature. This resolves the missing ConnectionFactory problem. 2) Under multi-threaded conditions, the JAXRS Clients fail with the following exception: javax.ws.rs.client.ResponseProcessingException: Problem with reading the data, class java.lang.String, ContentType: text/plain. at org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:438) at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:378) at org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:521) at org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:817) at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:760) at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228) at com.sun.proxy.$Proxy24.doSimpleMethod(Unknown Source) at com.ge.testcase.ThreadingTest$ThreadedRSJMSTest.run(ThreadingTest.java:132) at java.lang.Thread.run(Thread.java:745) Caused by: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) at java.util.HashMap$EntryIterator.next(HashMap.java:1463) at java.util.HashMap$EntryIterator.next(HashMap.java:1461) at java.util.HashMap.putMapEntries(HashMap.java:511) at java.util.HashMap.putAll(HashMap.java:784) at org.apache.cxf.message.MessageImpl$1.putAll(MessageImpl.java:188) at org.apache.cxf.message.MessageImpl.calcContextCache(MessageImpl.java:213) at org.apache.cxf.message.MessageImpl.getContextualProperty(MessageImpl.java:174) at org.apache.cxf.jaxrs.impl.HttpHeadersImpl.getRequestHeaders(HttpHeadersImpl.java:172) at org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1345) at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:369) ... 7 more This occurs even though the 'ThreadSafe' property is set via: rsClientFactory.setThreadSafe(true); I've done quite a large amount of digging through the code to try and narrow down the scope of the problem, and the results above is as far as I could get, unfortunately. My guess/assumption is that there are some JMS-specific objects that are being added to the Request/Response context which are being added/removed in a non-thread safe way. Purely a guess, though. Finally, one important factor is that this error only happens on the latest 3.0.x release (3.0.11). When I switch my test case to 3.1.8, it does NOT occur. Not sure if this equates to a fix not being back-ported, or a fundamental difference in functionality. Sadly, we're not able to yet move to 3.1.x, because of running inside the Karaf container, and our dependencies on Camel and Spring 3.x. Thanks. Please let me know if you need any other information. was: Our platform allows the user to switch transports for a particular proxy based on configuration. We currently allow HTTP and JMS as possible options. During recent performance testing, we've hit a bug which causes JAXRS Clients over JMS to fail with a ConcurrentModificationException: A test case is attached that reproduces our problem. Our test executes requests across multiple concurrent threads, switching between JMS and HTTP for
[jira] [Created] (CXF-7137) Allow OAuth2 customization via Swagger2Feature
Alexander K. created CXF-7137: - Summary: Allow OAuth2 customization via Swagger2Feature Key: CXF-7137 URL: https://issues.apache.org/jira/browse/CXF-7137 Project: CXF Issue Type: Improvement Components: JAX-RS Affects Versions: 3.1.8 Reporter: Alexander K. It seems that there is no way to customize initOAuth() details like clientId, clientSecret, realm, appName, etc. for SwaggerUI-OAuth integration. This will allow Swagger-UI authorization for protected CXF REST services by an authorization server such as Keycloak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-7135) ConcurrentModificationException in MessageImpl.calcContextCache() when using JMS Transport and JAXRS Client
[ https://issues.apache.org/jira/browse/CXF-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Salt updated CXF-7135: -- Description: Our platform allows the user to switch transports for a particular proxy based on configuration. We currently allow HTTP and JMS as possible options. During recent performance testing, we've hit a bug which causes JAXRS Clients over JMS to fail with a ConcurrentModificationException: A test case is attached that reproduces our problem. Our test executes requests across multiple concurrent threads, switching between JMS and HTTP for both JAXWS and JAXRS Client Proxies. In the test case: - JAXWS over both HTTP and JMS works fine, both in single and multi-threaded tests. - JAXRS works fine across single and multi-threaded tests over HTTP with the 'ThreadSafe' flag set on the Client Factory. - JAXRS over JMS fails in both single-threaded and multi-threaded mode with error (1) below. In multi-threaded, also fails with (2) below. 1) The ConnectionFactoryFeature fails to properly set the JMS Connection Factory on the Conduit and results in an error at send-time because no Connection Factory is set. This is because in JAXRS Clients, the InterceptorProvider is neither a Client or Server, it is a ClientConfiguration, so the JMS ConnectionFactoryFeature does not fire either of it's methods: public void initialize(Client client, Bus bus) public void initialize(Server server, Bus bus) We have worked around this in our code by sub-classing and overriding the method: public void initialize(InterceptorProvider interceptorProvider, Bus bus) .. and adding code similar to that in the ConnectionFactory feature. This resolves the missing ConnectionFactory problem and JAXRS-over-JMS works fine in single-threaded mode. 2) Under multi-threaded conditions, the JAXRS Clients fail with the following exception: javax.ws.rs.client.ResponseProcessingException: Problem with reading the data, class java.lang.String, ContentType: text/plain. at org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:438) at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:378) at org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:521) at org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:817) at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:760) at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228) at com.sun.proxy.$Proxy24.doSimpleMethod(Unknown Source) at com.ge.testcase.ThreadingTest$ThreadedRSJMSTest.run(ThreadingTest.java:132) at java.lang.Thread.run(Thread.java:745) Caused by: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) at java.util.HashMap$EntryIterator.next(HashMap.java:1463) at java.util.HashMap$EntryIterator.next(HashMap.java:1461) at java.util.HashMap.putMapEntries(HashMap.java:511) at java.util.HashMap.putAll(HashMap.java:784) at org.apache.cxf.message.MessageImpl$1.putAll(MessageImpl.java:188) at org.apache.cxf.message.MessageImpl.calcContextCache(MessageImpl.java:213) at org.apache.cxf.message.MessageImpl.getContextualProperty(MessageImpl.java:174) at org.apache.cxf.jaxrs.impl.HttpHeadersImpl.getRequestHeaders(HttpHeadersImpl.java:172) at org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1345) at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:369) ... 7 more This occurs even though the 'ThreadSafe' property is set via: rsClientFactory.setThreadSafe(true); I've done quite a large amount of digging through the code to try and narrow down the scope of the problem, and the results above is as far as I could get, unfortunately. My guess/assumption is that there are some JMS-specific objects that are being added to the Request/Response context which are being added/removed in a non-thread safe way. Purely a guess, though. Finally, one important factor is that this error only happens on the latest 3.0.x release (3.0.11). When I switch my test case to 3.1.8, it does NOT occur. Not sure if this equates to a fix not being back-ported, or a fundamental difference in functionality. Sadly, we're not able to yet move to 3.1.x, because of running inside the Karaf container, and our dependencies on Camel and Spring 3.x. Thanks. Please let me know if you need any other information. was: Our platform allows the user to switch transports for a particular proxy based on configuration. We currently allow HTTP and JMS as possible options. During recent performance testing, we've hit a bug which causes JAXRS Clients over JMS to fail with a ConcurrentModificationException:
[jira] [Updated] (CXF-7135) ConcurrentModificationException in MessageImpl.calcContextCache() when using JMS Transport and JAXRS Client
[ https://issues.apache.org/jira/browse/CXF-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Salt updated CXF-7135: -- Description: Our platform allows the user to switch transports for a particular proxy based on configuration. We currently allow HTTP and JMS as possible options. During recent performance testing, we've hit a bug which causes JAXRS Clients over JMS to fail with a ConcurrentModificationException: A test case is attached that reproduces our problem. Our test executes requests across multiple concurrent threads, switching between JMS and HTTP for both JAXWS and JAXRS Client Proxies. In the test case: - JAXWS over both HTTP and JMS works fine, both in single and multi-threaded tests. - JAXRS works fine across single and multi-threaded tests over HTTP with the 'ThreadSafe' flag set on the Client Factory. - JAXRS over JMS fails in both single-threaded and multi-threaded mode with error (1) below. In multi-threaded, also fails with (2) below. 1) The ConnectionFactoryFeature fails to properly set the JMS Connection Factory on the Conduit and results in an error at send-time because no Connection Factory is set. This is because in JAXRS Clients, the InterceptorProvider is neither a Client or Server, it is a ClientConfiguration, so the JMS ConnectionFactoryFeature does not fire either of it's methods: public void initialize(Client client, Bus bus) public void initialize(Server server, Bus bus) We have worked around this in our code by sub-classing and overriding the method: public void initialize(InterceptorProvider interceptorProvider, Bus bus) .. and adding code similar to that in the ConnectionFactory feature. This resolves the missing ConnectionFactory problem and JAXRS-over-JMS works fine in single-threaded mode. 2) Under multi-threaded conditions, the JAXRS Clients fail with the following exception: javax.ws.rs.client.ResponseProcessingException: Problem with reading the data, class java.lang.String, ContentType: text/plain. at org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:438) at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:378) at org.apache.cxf.jaxrs.client.AbstractClient.readBody(AbstractClient.java:521) at org.apache.cxf.jaxrs.client.ClientProxyImpl.handleResponse(ClientProxyImpl.java:817) at org.apache.cxf.jaxrs.client.ClientProxyImpl.doChainedInvocation(ClientProxyImpl.java:760) at org.apache.cxf.jaxrs.client.ClientProxyImpl.invoke(ClientProxyImpl.java:228) at com.sun.proxy.$Proxy24.doSimpleMethod(Unknown Source) at com.ge.testcase.ThreadingTest$ThreadedRSJMSTest.run(ThreadingTest.java:132) at java.lang.Thread.run(Thread.java:745) Caused by: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) at java.util.HashMap$EntryIterator.next(HashMap.java:1463) at java.util.HashMap$EntryIterator.next(HashMap.java:1461) at java.util.HashMap.putMapEntries(HashMap.java:511) at java.util.HashMap.putAll(HashMap.java:784) at org.apache.cxf.message.MessageImpl$1.putAll(MessageImpl.java:188) at org.apache.cxf.message.MessageImpl.calcContextCache(MessageImpl.java:213) at org.apache.cxf.message.MessageImpl.getContextualProperty(MessageImpl.java:174) at org.apache.cxf.jaxrs.impl.HttpHeadersImpl.getRequestHeaders(HttpHeadersImpl.java:172) at org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1345) at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:369) ... 7 more This occurs even though the 'ThreadSafe' property is set via: rsClientFactory.setThreadSafe(true); Also, interestingly, this exception occurs even if I put the entire Proxy Client invocation in a synchronized block (which should effectively render the Clients single-threaded). Finally, one important factor is that this error only happens on the latest 3.0.x release (3.0.11). When I switch my test case to 3.1.8, it does NOT occur. Not sure if this equates to a fix not being back-ported, or a fundamental difference in functionality. Sadly, we're not able to yet move to 3.1.x, because of running inside the Karaf container, and our dependencies on Camel and Spring 3.x. I've done quite a large amount of digging through the code to try and narrow down the scope of the problem, and the results above is as far as I could get, unfortunately. My guess/assumption is that there are some JMS-specific objects that are being added to the Request/Response context which are being added/removed in a non-thread safe way. Purely a guess, though. Thanks. Please let me know if you need any other information. was: Our platform allows the user to switch transports for a particular proxy based on configuration. We curre
[jira] [Created] (CXF-7138) Logging interceptor is logging binary content
Marcin Gorgoń created CXF-7138:
--
Summary: Logging interceptor is logging binary content
Key: CXF-7138
URL: https://issues.apache.org/jira/browse/CXF-7138
Project: CXF
Issue Type: Bug
Components: logging
Affects Versions: 3.1.7
Reporter: Marcin Gorgoń
LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
event if showBinaryContent is set to false.
Actually, AbstractLoggingInterceptor has defined only few binary content media
types:
BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
BINARY_CONTENT_MEDIA_TYPES.add("image/png");
BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
When ZIP or PDF files are transmitted in XOP payload, they are not recognized
as binary content and are logged.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7138) Logging interceptor is logging binary content
[
https://issues.apache.org/jira/browse/CXF-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Gorgoń updated CXF-7138:
---
Description:
LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
even when showBinaryContent is set to false (whis is it's default value).
Actually, AbstractLoggingInterceptor has defined only few binary content media
types:
BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
BINARY_CONTENT_MEDIA_TYPES.add("image/png");
BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
When ZIP or PDF files are transmitted in XOP payload, they are not recognized
as binary content and are logged.
This enforces users writting their own filters, which should be provided by
default, when showBinaryContent is set to false.
was:
LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
even when showBinaryContent is set to false.
Actually, AbstractLoggingInterceptor has defined only few binary content media
types:
BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
BINARY_CONTENT_MEDIA_TYPES.add("image/png");
BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
When ZIP or PDF files are transmitted in XOP payload, they are not recognized
as binary content and are logged.
This enforces users writting their own filters, which should be provided by
default, when showBinaryContent is set to false.
> Logging interceptor is logging binary content
> -
>
> Key: CXF-7138
> URL: https://issues.apache.org/jira/browse/CXF-7138
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.1.7
>Reporter: Marcin Gorgoń
>
> LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
> even when showBinaryContent is set to false (whis is it's default value).
> Actually, AbstractLoggingInterceptor has defined only few binary content
> media types:
> BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
> BINARY_CONTENT_MEDIA_TYPES.add("image/png");
> BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
> BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
> When ZIP or PDF files are transmitted in XOP payload, they are not recognized
> as binary content and are logged.
> This enforces users writting their own filters, which should be provided by
> default, when showBinaryContent is set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7138) Logging interceptor is logging binary content
[
https://issues.apache.org/jira/browse/CXF-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Gorgoń updated CXF-7138:
---
Description:
LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
event if showBinaryContent is set to false.
Actually, AbstractLoggingInterceptor has defined only few binary content media
types:
BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
BINARY_CONTENT_MEDIA_TYPES.add("image/png");
BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
When ZIP or PDF files are transmitted in XOP payload, they are not recognized
as binary content and are logged.
This enforces users writting their own filters, which should be provided by
default, when showBinaryContent is set to false.
was:
LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
event if showBinaryContent is set to false.
Actually, AbstractLoggingInterceptor has defined only few binary content media
types:
BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
BINARY_CONTENT_MEDIA_TYPES.add("image/png");
BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
When ZIP or PDF files are transmitted in XOP payload, they are not recognized
as binary content and are logged.
> Logging interceptor is logging binary content
> -
>
> Key: CXF-7138
> URL: https://issues.apache.org/jira/browse/CXF-7138
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.1.7
>Reporter: Marcin Gorgoń
>
> LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
> event if showBinaryContent is set to false.
> Actually, AbstractLoggingInterceptor has defined only few binary content
> media types:
> BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
> BINARY_CONTENT_MEDIA_TYPES.add("image/png");
> BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
> BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
> When ZIP or PDF files are transmitted in XOP payload, they are not recognized
> as binary content and are logged.
> This enforces users writting their own filters, which should be provided by
> default, when showBinaryContent is set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7138) Logging interceptor is logging binary content
[
https://issues.apache.org/jira/browse/CXF-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Gorgoń updated CXF-7138:
---
Description:
LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
even when showBinaryContent is set to false (which is it's default value).
Actually, AbstractLoggingInterceptor has defined only few binary content media
types:
BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
BINARY_CONTENT_MEDIA_TYPES.add("image/png");
BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
When ZIP or PDF files are transmitted in XOP payload, they are not recognized
as binary content and are logged.
This enforces users writting their own filters, which should be provided by
default, when showBinaryContent is set to false.
was:
LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
even when showBinaryContent is set to false (whis is it's default value).
Actually, AbstractLoggingInterceptor has defined only few binary content media
types:
BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
BINARY_CONTENT_MEDIA_TYPES.add("image/png");
BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
When ZIP or PDF files are transmitted in XOP payload, they are not recognized
as binary content and are logged.
This enforces users writting their own filters, which should be provided by
default, when showBinaryContent is set to false.
> Logging interceptor is logging binary content
> -
>
> Key: CXF-7138
> URL: https://issues.apache.org/jira/browse/CXF-7138
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.1.7
>Reporter: Marcin Gorgoń
>
> LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
> even when showBinaryContent is set to false (which is it's default value).
> Actually, AbstractLoggingInterceptor has defined only few binary content
> media types:
> BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
> BINARY_CONTENT_MEDIA_TYPES.add("image/png");
> BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
> BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
> When ZIP or PDF files are transmitted in XOP payload, they are not recognized
> as binary content and are logged.
> This enforces users writting their own filters, which should be provided by
> default, when showBinaryContent is set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7138) Logging interceptor is logging binary content
[
https://issues.apache.org/jira/browse/CXF-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Gorgoń updated CXF-7138:
---
Description:
LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
even when showBinaryContent is set to false.
Actually, AbstractLoggingInterceptor has defined only few binary content media
types:
BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
BINARY_CONTENT_MEDIA_TYPES.add("image/png");
BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
When ZIP or PDF files are transmitted in XOP payload, they are not recognized
as binary content and are logged.
This enforces users writting their own filters, which should be provided by
default, when showBinaryContent is set to false.
was:
LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
event if showBinaryContent is set to false.
Actually, AbstractLoggingInterceptor has defined only few binary content media
types:
BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
BINARY_CONTENT_MEDIA_TYPES.add("image/png");
BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
When ZIP or PDF files are transmitted in XOP payload, they are not recognized
as binary content and are logged.
This enforces users writting their own filters, which should be provided by
default, when showBinaryContent is set to false.
> Logging interceptor is logging binary content
> -
>
> Key: CXF-7138
> URL: https://issues.apache.org/jira/browse/CXF-7138
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.1.7
>Reporter: Marcin Gorgoń
>
> LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
> even when showBinaryContent is set to false.
> Actually, AbstractLoggingInterceptor has defined only few binary content
> media types:
> BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
> BINARY_CONTENT_MEDIA_TYPES.add("image/png");
> BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
> BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
> When ZIP or PDF files are transmitted in XOP payload, they are not recognized
> as binary content and are logged.
> This enforces users writting their own filters, which should be provided by
> default, when showBinaryContent is set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7139) BufferOverflowException when decoding a parameter values with a trailing %
Michael Grant created CXF-7139:
--
Summary: BufferOverflowException when decoding a parameter values
with a trailing %
Key: CXF-7139
URL: https://issues.apache.org/jira/browse/CXF-7139
Project: CXF
Issue Type: Bug
Components: Core
Affects Versions: 3.1.0, 3.0.4
Reporter: Michael Grant
Priority: Minor
{code}
java.nio.BufferOverflowException
at java.nio.Buffer.nextPutIndex(Buffer.java:521)
at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:169)
at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:102)
at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:67)
at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:122)
at org.apache.cxf.jaxrs.utils.HttpUtils.urlDecode(HttpUtils.java:97)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1262)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1236)
at
org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:115)
at
org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:109)
at
org.apache.cxf.jaxrs.impl.RequestPreprocessor.preprocess(RequestPreprocessor.java:74)
at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:102)
at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
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(Servlet
at org.apache.cxf.transport.servlet.ServletController.invoke(Servlet
at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNo
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleReques
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(Abstra
at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(Abst
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicat
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.jav
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicat
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrap
at org.apache.catalina.core.StandardContextValve.invoke(StandardCont
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authen
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostVal
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportVal
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Abstract
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngin
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter
at org.apache.coyote.http11.AbstractHttp11Processor.process(Abstract
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.proc
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioE
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEnd
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecu
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExec
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(Ta
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7139) BufferOverflowException when decoding a parameter values with a trailing %
[
https://issues.apache.org/jira/browse/CXF-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Grant updated CXF-7139:
---
Description:
When a parameter value contains a trailing {{%}}, a {{BufferOverflowException}}
is thrown.
e.g. a query to our service containing
{{http://localhost:8080/test/?parameter=test%}}
{code}
java.nio.BufferOverflowException
at java.nio.Buffer.nextPutIndex(Buffer.java:521)
at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:169)
at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:102)
at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:67)
at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:122)
at org.apache.cxf.jaxrs.utils.HttpUtils.urlDecode(HttpUtils.java:97)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1262)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1236)
at
org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:115)
at
org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:109)
at
org.apache.cxf.jaxrs.impl.RequestPreprocessor.preprocess(RequestPreprocessor.java:74)
at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:102)
at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
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(Servlet
at org.apache.cxf.transport.servlet.ServletController.invoke(Servlet
at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNo
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleReques
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(Abstra
at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(Abst
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicat
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.jav
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
at org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicat
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrap
at org.apache.catalina.core.StandardContextValve.invoke(StandardCont
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authen
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostVal
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportVal
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Abstract
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngin
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter
at org.apache.coyote.http11.AbstractHttp11Processor.process(Abstract
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.proc
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioE
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEnd
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecu
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExec
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(Ta
at java.lang.Thread.run(Thread.java:745)
{code}
was:
{code}
java.nio.BufferOverflowException
at java.nio.Buffer.nextPutIndex(Buffer.java:521)
at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:169)
at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:102)
at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:67)
at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:122)
at org.apache.cxf.jaxrs.utils.HttpUtils.urlDecode(HttpUtils.java:97)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1262)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1236)
at
org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:115)
at
org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:109)
at
org.apache.cxf.jaxrs.impl.RequestPreprocessor.preprocess(Request
[jira] [Commented] (CXF-7139) BufferOverflowException when decoding a parameter values with a trailing %
[
https://issues.apache.org/jira/browse/CXF-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671658#comment-15671658
]
Michael Grant commented on CXF-7139:
I believe this is due to an optimisation in CXF-6189.
{code:java}
final byte[] valueBytes = StringUtils.toBytes(value, enc);
ByteBuffer in = ByteBuffer.wrap(valueBytes);
ByteBuffer out = ByteBuffer.allocate(in.capacity() - 2 * escapesCount);
{code}
Removing {{2 * escapesCount}} from the capacity of {{out}} allows the {{out}}
capacity to be set to a value that is too small if a trailing {{%}} is included
in the parameter.
A simple solution is to always add and extra 1 to the {{out}} capacity (giving
it enough capacity to add to until the invalid URL encoding is spotted).
> BufferOverflowException when decoding a parameter values with a trailing %
> --
>
> Key: CXF-7139
> URL: https://issues.apache.org/jira/browse/CXF-7139
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.4, 3.1.0
>Reporter: Michael Grant
>Priority: Minor
>
> When a parameter value contains a trailing {{%}}, a
> {{BufferOverflowException}} is thrown.
> e.g. a query to our service containing
> {{http://localhost:8080/test/?parameter=test%}}
> {code}
> java.nio.BufferOverflowException
> at java.nio.Buffer.nextPutIndex(Buffer.java:521)
> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:169)
> at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:102)
> at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:67)
> at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:122)
> at org.apache.cxf.jaxrs.utils.HttpUtils.urlDecode(HttpUtils.java:97)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1262)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1236)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:115)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:109)
> at
> org.apache.cxf.jaxrs.impl.RequestPreprocessor.preprocess(RequestPreprocessor.java:74)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:102)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> 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(Servlet
> at org.apache.cxf.transport.servlet.ServletController.invoke(Servlet
> at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNo
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleReques
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(Abstra
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(Abst
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicat
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.jav
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicat
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrap
> at org.apache.catalina.core.StandardContextValve.invoke(StandardCont
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authen
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostVal
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportVal
> at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Abstract
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngin
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter
> at org.apache.coyote.http11.AbstractHttp11Processor.process(Abstract
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.proc
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioE
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEnd
> at java.u
[jira] [Commented] (CXF-7139) BufferOverflowException when decoding a parameter values with a trailing %
[
https://issues.apache.org/jira/browse/CXF-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671705#comment-15671705
]
ASF GitHub Bot commented on CXF-7139:
-
GitHub user iammichaelgrant opened a pull request:
https://github.com/apache/cxf/pull/201
[CXF-7139] Avoid BufferOverflowException for trailing escape characters
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/iammichaelgrant/cxf master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/201.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 #201
commit d8d28b2e62c09b63cab4dcb5794712806826113d
Author: Michael Grant
Date: 2016-11-16T21:30:45Z
[CXF-7139] Avoid BufferOverflowException for trailing escape characters
> BufferOverflowException when decoding a parameter values with a trailing %
> --
>
> Key: CXF-7139
> URL: https://issues.apache.org/jira/browse/CXF-7139
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.4, 3.1.0
>Reporter: Michael Grant
>Priority: Minor
>
> When a parameter value contains a trailing {{%}}, a
> {{BufferOverflowException}} is thrown.
> e.g. a query to our service containing
> {{http://localhost:8080/test/?parameter=test%}}
> {code}
> java.nio.BufferOverflowException
> at java.nio.Buffer.nextPutIndex(Buffer.java:521)
> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:169)
> at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:102)
> at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:67)
> at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:122)
> at org.apache.cxf.jaxrs.utils.HttpUtils.urlDecode(HttpUtils.java:97)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1262)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1236)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:115)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:109)
> at
> org.apache.cxf.jaxrs.impl.RequestPreprocessor.preprocess(RequestPreprocessor.java:74)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:102)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> 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(Servlet
> at org.apache.cxf.transport.servlet.ServletController.invoke(Servlet
> at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNo
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleReques
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(Abstra
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(Abst
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicat
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.jav
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicat
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrap
> at org.apache.catalina.core.StandardContextValve.invoke(StandardCont
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authen
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostVal
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportVal
> at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Abstract
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngin
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter
> at org.apache.coyote.http11.AbstractHttp11Processor.process(Abstract
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHand
[jira] [Created] (CXF-7140) Multiple calls to AsyncResponse.cancel() returns different values
Andy McCright created CXF-7140: -- Summary: Multiple calls to AsyncResponse.cancel() returns different values Key: CXF-7140 URL: https://issues.apache.org/jira/browse/CXF-7140 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.1.8 Reporter: Andy McCright When we incorporated CXF 3.1.8 into our builds, our CTS testing team found some failures related to the AsyncResponse.cancel(...) methods. According to the spec, once the AsyncResponse has been canceled, subsequent calls to cancel should return true. It looks like one of the changes in CXF-7037 changed the order of things in the doCancel method -- and those changes result in false getting returned when calling cancel(...) a second time. I have written some tests that demonstrate the expected CTS behavior - and they fail with the current code, but pass when reverting the order change in doCancel(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7140) Multiple calls to AsyncResponse.cancel() returns different values
[ https://issues.apache.org/jira/browse/CXF-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671853#comment-15671853 ] ASF GitHub Bot commented on CXF-7140: - GitHub user andymc12 opened a pull request: https://github.com/apache/cxf/pull/202 CXF-7140: Ensure AsyncResponse.cancel(...) behaves the same when invoked twice. You can merge this pull request into a Git repository by running: $ git pull https://github.com/andymc12/cxf asyncRespTest Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/202.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 #202 commit 03ff5c7419ee48ded3a7ce5155186263efb46ce0 Author: andymc12 Date: 2016-11-16T22:05:40Z Ensure AsyncResponse.cancel(...) behaves the same when invoked twice. > Multiple calls to AsyncResponse.cancel() returns different values > - > > Key: CXF-7140 > URL: https://issues.apache.org/jira/browse/CXF-7140 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.8 >Reporter: Andy McCright > > When we incorporated CXF 3.1.8 into our builds, our CTS testing team found > some failures related to the AsyncResponse.cancel(...) methods. According to > the spec, once the AsyncResponse has been canceled, subsequent calls to > cancel should return true. > It looks like one of the changes in CXF-7037 changed the order of things in > the doCancel method -- and those changes result in false getting returned > when calling cancel(...) a second time. > I have written some tests that demonstrate the expected CTS behavior - and > they fail with the current code, but pass when reverting the order change in > doCancel(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7140) Multiple calls to AsyncResponse.cancel() returns different values
[ https://issues.apache.org/jira/browse/CXF-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671921#comment-15671921 ] ASF GitHub Bot commented on CXF-7140: - Github user asfgit closed the pull request at: https://github.com/apache/cxf/pull/202 > Multiple calls to AsyncResponse.cancel() returns different values > - > > Key: CXF-7140 > URL: https://issues.apache.org/jira/browse/CXF-7140 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.8 >Reporter: Andy McCright > > When we incorporated CXF 3.1.8 into our builds, our CTS testing team found > some failures related to the AsyncResponse.cancel(...) methods. According to > the spec, once the AsyncResponse has been canceled, subsequent calls to > cancel should return true. > It looks like one of the changes in CXF-7037 changed the order of things in > the doCancel method -- and those changes result in false getting returned > when calling cancel(...) a second time. > I have written some tests that demonstrate the expected CTS behavior - and > they fail with the current code, but pass when reverting the order change in > doCancel(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7139) BufferOverflowException when decoding a parameter values with a trailing %
[
https://issues.apache.org/jira/browse/CXF-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671922#comment-15671922
]
ASF GitHub Bot commented on CXF-7139:
-
Github user asfgit closed the pull request at:
https://github.com/apache/cxf/pull/201
> BufferOverflowException when decoding a parameter values with a trailing %
> --
>
> Key: CXF-7139
> URL: https://issues.apache.org/jira/browse/CXF-7139
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.4, 3.1.0
>Reporter: Michael Grant
>Priority: Minor
>
> When a parameter value contains a trailing {{%}}, a
> {{BufferOverflowException}} is thrown.
> e.g. a query to our service containing
> {{http://localhost:8080/test/?parameter=test%}}
> {code}
> java.nio.BufferOverflowException
> at java.nio.Buffer.nextPutIndex(Buffer.java:521)
> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:169)
> at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:102)
> at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:67)
> at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:122)
> at org.apache.cxf.jaxrs.utils.HttpUtils.urlDecode(HttpUtils.java:97)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1262)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1236)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:115)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:109)
> at
> org.apache.cxf.jaxrs.impl.RequestPreprocessor.preprocess(RequestPreprocessor.java:74)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:102)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> 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(Servlet
> at org.apache.cxf.transport.servlet.ServletController.invoke(Servlet
> at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNo
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleReques
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(Abstra
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(Abst
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicat
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.jav
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicat
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrap
> at org.apache.catalina.core.StandardContextValve.invoke(StandardCont
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authen
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostVal
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportVal
> at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Abstract
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngin
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter
> at org.apache.coyote.http11.AbstractHttp11Processor.process(Abstract
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.proc
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioE
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEnd
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecu
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExec
> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(Ta
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7139) BufferOverflowException when decoding a parameter values with a trailing %
[
https://issues.apache.org/jira/browse/CXF-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671975#comment-15671975
]
Sergey Beryozkin commented on CXF-7139:
---
Thanks for the patch
> BufferOverflowException when decoding a parameter values with a trailing %
> --
>
> Key: CXF-7139
> URL: https://issues.apache.org/jira/browse/CXF-7139
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.4, 3.1.0
>Reporter: Michael Grant
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.2.0, 3.1.9, 3.0.12
>
>
> When a parameter value contains a trailing {{%}}, a
> {{BufferOverflowException}} is thrown.
> e.g. a query to our service containing
> {{http://localhost:8080/test/?parameter=test%}}
> {code}
> java.nio.BufferOverflowException
> at java.nio.Buffer.nextPutIndex(Buffer.java:521)
> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:169)
> at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:102)
> at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:67)
> at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:122)
> at org.apache.cxf.jaxrs.utils.HttpUtils.urlDecode(HttpUtils.java:97)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1262)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1236)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:115)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:109)
> at
> org.apache.cxf.jaxrs.impl.RequestPreprocessor.preprocess(RequestPreprocessor.java:74)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:102)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> 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(Servlet
> at org.apache.cxf.transport.servlet.ServletController.invoke(Servlet
> at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNo
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleReques
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(Abstra
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(Abst
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicat
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.jav
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicat
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrap
> at org.apache.catalina.core.StandardContextValve.invoke(StandardCont
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authen
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostVal
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportVal
> at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Abstract
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngin
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter
> at org.apache.coyote.http11.AbstractHttp11Processor.process(Abstract
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.proc
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioE
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEnd
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecu
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExec
> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(Ta
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-7139) BufferOverflowException when decoding a parameter values with a trailing %
[
https://issues.apache.org/jira/browse/CXF-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-7139.
---
Resolution: Fixed
Assignee: Sergey Beryozkin
Fix Version/s: 3.0.12
3.1.9
3.2.0
> BufferOverflowException when decoding a parameter values with a trailing %
> --
>
> Key: CXF-7139
> URL: https://issues.apache.org/jira/browse/CXF-7139
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.4, 3.1.0
>Reporter: Michael Grant
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.2.0, 3.1.9, 3.0.12
>
>
> When a parameter value contains a trailing {{%}}, a
> {{BufferOverflowException}} is thrown.
> e.g. a query to our service containing
> {{http://localhost:8080/test/?parameter=test%}}
> {code}
> java.nio.BufferOverflowException
> at java.nio.Buffer.nextPutIndex(Buffer.java:521)
> at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:169)
> at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:102)
> at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:67)
> at org.apache.cxf.common.util.UrlUtils.urlDecode(UrlUtils.java:122)
> at org.apache.cxf.jaxrs.utils.HttpUtils.urlDecode(HttpUtils.java:97)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1262)
> at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.getStructuredParams(JAXRSUtils.java:1236)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:115)
> at
> org.apache.cxf.jaxrs.impl.UriInfoImpl.getQueryParameters(UriInfoImpl.java:109)
> at
> org.apache.cxf.jaxrs.impl.RequestPreprocessor.preprocess(RequestPreprocessor.java:74)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:102)
> at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> 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(Servlet
> at org.apache.cxf.transport.servlet.ServletController.invoke(Servlet
> at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNo
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleReques
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(Abstra
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(Abst
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicat
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.jav
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicat
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrap
> at org.apache.catalina.core.StandardContextValve.invoke(StandardCont
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authen
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostVal
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportVal
> at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Abstract
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngin
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter
> at org.apache.coyote.http11.AbstractHttp11Processor.process(Abstract
> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.proc
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioE
> at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEnd
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecu
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExec
> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(Ta
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-7140) Multiple calls to AsyncResponse.cancel() returns different values
[ https://issues.apache.org/jira/browse/CXF-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-7140. --- Resolution: Fixed Assignee: Sergey Beryozkin Fix Version/s: 3.0.12 3.1.9 3.2.0 Thanks for the patch, unfortunately, before your patch has been applied, only a (system) test testing a single cancel was available. > Multiple calls to AsyncResponse.cancel() returns different values > - > > Key: CXF-7140 > URL: https://issues.apache.org/jira/browse/CXF-7140 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.8 >Reporter: Andy McCright >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.9, 3.0.12 > > > When we incorporated CXF 3.1.8 into our builds, our CTS testing team found > some failures related to the AsyncResponse.cancel(...) methods. According to > the spec, once the AsyncResponse has been canceled, subsequent calls to > cancel should return true. > It looks like one of the changes in CXF-7037 changed the order of things in > the doCancel method -- and those changes result in false getting returned > when calling cancel(...) a second time. > I have written some tests that demonstrate the expected CTS behavior - and > they fail with the current code, but pass when reverting the order change in > doCancel(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7137) Allow OAuth2 customization via Swagger2Feature
[ https://issues.apache.org/jira/browse/CXF-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671997#comment-15671997 ] Sergey Beryozkin commented on CXF-7137: --- Hi, as far as I'm aware, a client secret is only issued by Authorization Service only after the successful client registration, with a (confidential web server) client keeping it private and only using when talking to AccessTokenService. I don't understand why would this client make this secret visible as part of its Swagger API Docs - that would a security leak. Can you explain please how does it work ? Thanks > Allow OAuth2 customization via Swagger2Feature > -- > > Key: CXF-7137 > URL: https://issues.apache.org/jira/browse/CXF-7137 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.8 >Reporter: Alexander K. > > It seems that there is no way to customize initOAuth() details like clientId, > clientSecret, realm, appName, etc. for SwaggerUI-OAuth integration. This will > allow Swagger-UI authorization for protected CXF REST services by an > authorization server such as Keycloak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7138) Logging interceptor is logging binary content
[
https://issues.apache.org/jira/browse/CXF-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672006#comment-15672006
]
Sergey Beryozkin commented on CXF-7138:
---
Hi, in this case you need to set a 'showMultipartContent' to false.
'showBinaryContent' applies to the cases when the binary content is included
directly in the request body, not as a multipart part
> Logging interceptor is logging binary content
> -
>
> Key: CXF-7138
> URL: https://issues.apache.org/jira/browse/CXF-7138
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.1.7
>Reporter: Marcin Gorgoń
>
> LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
> even when showBinaryContent is set to false (which is it's default value).
> Actually, AbstractLoggingInterceptor has defined only few binary content
> media types:
> BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
> BINARY_CONTENT_MEDIA_TYPES.add("image/png");
> BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
> BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
> When ZIP or PDF files are transmitted in XOP payload, they are not recognized
> as binary content and are logged.
> This enforces users writting their own filters, which should be provided by
> default, when showBinaryContent is set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7117) Swagger2Feature not working in OSGi container when jaxrs server address not attached to CXF servlet
[
https://issues.apache.org/jira/browse/CXF-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672347#comment-15672347
]
Andriy Redko commented on CXF-7117:
---
Hey [~nsaboy],
I have just committed a fix to 3.1.x-fixes branch (3.1.9-SNAPSHOT). It seems to
work pretty good, could you please give it a try?
Thanks a lot!
Best Regards,
Andriy Redko
> Swagger2Feature not working in OSGi container when jaxrs server address not
> attached to CXF servlet
> ---
>
> Key: CXF-7117
> URL: https://issues.apache.org/jira/browse/CXF-7117
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.8
> Environment: Apache Karaf 3.0.8
>Reporter: Concombre Masqué
>Assignee: Andriy Redko
>
> Just modify sample description_swagger2_osgi as follows:
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
> address="http://localhost:9091/test/swaggerSample";>
>
>
>
>
>
>
>
>
>
>
>
>
> Then deploy modified bundle into Karaf and browse Swagger service definition
> at http://localhost:9091/test/swaggerSample/swagger.json
> Result is:
> {"swagger":"2.0"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
