[jira] [Created] (CXF-7150) CXF Swagger2Feature does not work in karaf when use equinox as the osgi framework
H.G vantaking created CXF-7150:
--
Summary: CXF Swagger2Feature does not work in karaf when use
equinox as the osgi framework
Key: CXF-7150
URL: https://issues.apache.org/jira/browse/CXF-7150
Project: CXF
Issue Type: Bug
Affects Versions: 3.1.8
Environment: karaf equinox
Reporter: H.G vantaking
It got ReflectionsException in org.reflections.Reflections and the warnning
{{could not create Vfs.Dir from url. ignoring the exception and continuing}}
--
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 ] Sergey Beryozkin updated CXF-7135: -- Assignee: Sergey Beryozkin Fix Version/s: 3.0.12 > 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 >Assignee: Sergey Beryozkin > Fix For: 3.0.12 > > 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: > - 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 tes
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15695786#comment-15695786 ] Lin Ye commented on CXF-7135: - I am currently out of the office returning Monday November 28th. Sorry for the inconvenience, and I'll respond to you as soon as I can. > 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 >Assignee: Sergey Beryozkin > Fix For: 3.0.12 > > 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: > - 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,
[jira] [Commented] (CXF-6930) Race-Condition with JMS-transport, LoggingInInterceptor spoils the payload while logging it
[
https://issues.apache.org/jira/browse/CXF-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15695960#comment-15695960
]
Sergey Beryozkin commented on CXF-6930:
---
I believe Dan had fixed it, can you try 3.1.8 please ?
> Race-Condition with JMS-transport, LoggingInInterceptor spoils the payload
> while logging it
> ---
>
> Key: CXF-6930
> URL: https://issues.apache.org/jira/browse/CXF-6930
> Project: CXF
> Issue Type: Bug
> Components: JMS
>Affects Versions: 3.1.6
>Reporter: Tobias Schöneberg
> Fix For: 3.1.8
>
>
> Hi,
> I think we stumbled over a problem with cxf and the JMS-transport,
> if the {{LoggingFeature}} is used to log incoming response messages.
> The problem is that sometimes, {{ClientProxyImpl.invoke(...)}} returns
> {{null}},
> but from the logged message payload, it's clear that there is a not-null
> response payload coming from the sever.
> I believe, I just figured out that it is in fact the logging of that very
> payload which causes {{ClientProxyImpl.invoke(...)}} to return {{null}}.
> How?
> There is a race between the actual "client thread" which waited for the
> server's response
> (i.e. {{exchange.wait()}} in {{JMSConduit.sendAndReceiveMessage(...)}} )
> until notified by the ActiveMQ Session Task thread
> (i.e. {{exchange.notifyAll()}} in {{JMSConduit.processReplyMessage(...)}} )
> one one side and the ActiveMQ Session Task thread itself on the other side.
> Once the client thread is notified, it goes on with {{preProcessResult(...)}}
> and {{handleResponse(...)}} and somewhere in there the message's
> {{ByteArrayStream}} is read and the return object is created.
> However, at the same time, back in the ActiveMQ thread, the interceptor chain
> is run.
> In my case it contains the {{LoggingInInterceptor}} which accesses the
> message's *same* {{ByteArrayInputStream}}, in the method
> {{LoggingInInterceptor.logInputStream(...)}} ).
> Now, in {{logInputStream(...)}}, we have
> {code:java}
> IOUtils.copyAtLeast(bis, bos, limit == -1 ? Integer.MAX_VALUE : limit);
> bos.flush();
> bis = new SequenceInputStream(bos.getInputStream(), bis);
> // restore the delegating input stream or the input stream
> if (is instanceof DelegatingInputStream) {
> ((DelegatingInputStream)is).setInputStream(bis);
> } else {
> message.setContent(InputStream.class, bis);
> }
> {code}
> My problem happens if the client thread tries to read the message while
> "{{bis}}" was read, but not yet restored. During that time, "{{bis}}" is
> closed for the in the client thread and it will skip over it (or throw an
> Exception, based on its config).
> My current best and maybe naive guess on how to solve this is to change the
> method {{JMSConduit.processReplyMessage(...)}}
> and execute the if-block around {{exchange.notifyAll();}} only after the
> if-block around {{incomingObserver.onMessage(exchange.getInMessage());}}
> WDYT?
> Best reagards
> Tobias
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6930) Race-Condition with JMS-transport, LoggingInInterceptor spoils the payload while logging it
[
https://issues.apache.org/jira/browse/CXF-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-6930.
---
Resolution: Fixed
Assignee: Daniel Kulp
Fix Version/s: 3.1.8
> Race-Condition with JMS-transport, LoggingInInterceptor spoils the payload
> while logging it
> ---
>
> Key: CXF-6930
> URL: https://issues.apache.org/jira/browse/CXF-6930
> Project: CXF
> Issue Type: Bug
> Components: JMS
>Affects Versions: 3.1.6
>Reporter: Tobias Schöneberg
>Assignee: Daniel Kulp
> Fix For: 3.1.8
>
>
> Hi,
> I think we stumbled over a problem with cxf and the JMS-transport,
> if the {{LoggingFeature}} is used to log incoming response messages.
> The problem is that sometimes, {{ClientProxyImpl.invoke(...)}} returns
> {{null}},
> but from the logged message payload, it's clear that there is a not-null
> response payload coming from the sever.
> I believe, I just figured out that it is in fact the logging of that very
> payload which causes {{ClientProxyImpl.invoke(...)}} to return {{null}}.
> How?
> There is a race between the actual "client thread" which waited for the
> server's response
> (i.e. {{exchange.wait()}} in {{JMSConduit.sendAndReceiveMessage(...)}} )
> until notified by the ActiveMQ Session Task thread
> (i.e. {{exchange.notifyAll()}} in {{JMSConduit.processReplyMessage(...)}} )
> one one side and the ActiveMQ Session Task thread itself on the other side.
> Once the client thread is notified, it goes on with {{preProcessResult(...)}}
> and {{handleResponse(...)}} and somewhere in there the message's
> {{ByteArrayStream}} is read and the return object is created.
> However, at the same time, back in the ActiveMQ thread, the interceptor chain
> is run.
> In my case it contains the {{LoggingInInterceptor}} which accesses the
> message's *same* {{ByteArrayInputStream}}, in the method
> {{LoggingInInterceptor.logInputStream(...)}} ).
> Now, in {{logInputStream(...)}}, we have
> {code:java}
> IOUtils.copyAtLeast(bis, bos, limit == -1 ? Integer.MAX_VALUE : limit);
> bos.flush();
> bis = new SequenceInputStream(bos.getInputStream(), bis);
> // restore the delegating input stream or the input stream
> if (is instanceof DelegatingInputStream) {
> ((DelegatingInputStream)is).setInputStream(bis);
> } else {
> message.setContent(InputStream.class, bis);
> }
> {code}
> My problem happens if the client thread tries to read the message while
> "{{bis}}" was read, but not yet restored. During that time, "{{bis}}" is
> closed for the in the client thread and it will skip over it (or throw an
> Exception, based on its config).
> My current best and maybe naive guess on how to solve this is to change the
> method {{JMSConduit.processReplyMessage(...)}}
> and execute the if-block around {{exchange.notifyAll();}} only after the
> if-block around {{incomingObserver.onMessage(exchange.getInMessage());}}
> WDYT?
> Best reagards
> Tobias
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (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 ] Sergey Beryozkin resolved CXF-7135. --- Resolution: Fixed > 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 >Assignee: Sergey Beryozkin > Fix For: 3.0.12 > > 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: > - 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.
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15696036#comment-15696036 ] Sergey Beryozkin commented on CXF-7135: --- Dan provided a fix for a similar JMS related issue earlier for 3.1.x and I ported it to 3.0.x, thanks > 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 >Assignee: Sergey Beryozkin > Fix For: 3.0.12 > > 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: > - 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 f
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15696041#comment-15696041 ] Dan Salt commented on CXF-7135: --- Sergey, That's great to hear! Many thanks for the super-fast resolution :) Cheers, Dan > 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 >Assignee: Sergey Beryozkin > Fix For: 3.0.12 > > 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: > - 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
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15696049#comment-15696049 ] Sergey Beryozkin commented on CXF-7135: --- Hi Dan, well, I was preparing to suffer for few more weeks, trying to find the fix :-), then I found that Dan Kulp's fix was not ported and this is when I acted really fast :-) Cheers, Sergey > 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 >Assignee: Sergey Beryozkin > Fix For: 3.0.12 > > 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: > - 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 (w
[jira] [Commented] (CXF-7124) PackageUtils.getSharedPackageName(List>) has bug
[
https://issues.apache.org/jira/browse/CXF-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696078#comment-15696078
]
Neal Hu commented on CXF-7124:
--
Dear Sergey,
Please reopen the ticket, the patch has bug.
{code:java}
@Test
public void testSharedPackageNameManyClassesCommonRoot6() {
String packageName = PackageUtils.getSharedPackageName(
Arrays.asList(org.apache.cxf.bus.spring.BusApplicationContext.class,
org.apache.cxf.configuration.spring.JAXBBeanFactory.class));
assertEquals("org.apache.cxf", packageName);
}
Failed tests:
PackageUtilsTest.testSharedPackageNameManyClassesCommonRoot6:101->Assert.assertEquals:144->Assert.assertEquals:115
expected: but was:
{code}
I will try to commit the new patch to github.
Thanks~
Neal
> PackageUtils.getSharedPackageName(List>) has bug
> -
>
> Key: CXF-7124
> URL: https://issues.apache.org/jira/browse/CXF-7124
> Project: CXF
> Issue Type: Bug
> Components: Core, JAX-RS
>Affects Versions: 3.1.7
> Environment: mac swagger
>Reporter: Neal Hu
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.9, 3.0.12
>
> Attachments: org.apache.cxf.common.util.PackageUtils.patch,
> org.apache.cxf.common.util.PackageUtilsTest.patch
>
>
> The swagger feature scans undefined api, the root cause is the util in
> PackageUtils has bug. For example:
> String packageName = PackageUtils.getSharedPackageName(
> Arrays.asList(org.apache.cxf.common.util.PackageUtils.class,
> org.apache.cxf.bus.CXFBusFactory.class,
> org.apache.cxf.common.jaxb.JAXBContextCache.class));
> Currently we get org.apache, but we should get org.apache.cxf.
> I have uploaded the patch and verified in the local environment, please
> review.
> --
> org.apache.cxf.jaxrs.swagger.AbstractSwaggerFeature.setResourcePackage(String)
> -->
> org.apache.cxf.common.util.PackageUtils.getSharedPackageName(List>)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7124) PackageUtils.getSharedPackageName(List>) has bug
[ https://issues.apache.org/jira/browse/CXF-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neal Hu updated CXF-7124: - Attachment: Fix_the_bug_of_PackageUtils.patch > PackageUtils.getSharedPackageName(List>) has bug > - > > Key: CXF-7124 > URL: https://issues.apache.org/jira/browse/CXF-7124 > Project: CXF > Issue Type: Bug > Components: Core, JAX-RS >Affects Versions: 3.1.7 > Environment: mac swagger >Reporter: Neal Hu >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.9, 3.0.12 > > Attachments: Fix_the_bug_of_PackageUtils.patch, > org.apache.cxf.common.util.PackageUtils.patch, > org.apache.cxf.common.util.PackageUtilsTest.patch > > > The swagger feature scans undefined api, the root cause is the util in > PackageUtils has bug. For example: > String packageName = PackageUtils.getSharedPackageName( > Arrays.asList(org.apache.cxf.common.util.PackageUtils.class, > org.apache.cxf.bus.CXFBusFactory.class, > org.apache.cxf.common.jaxb.JAXBContextCache.class)); > Currently we get org.apache, but we should get org.apache.cxf. > I have uploaded the patch and verified in the local environment, please > review. > -- > org.apache.cxf.jaxrs.swagger.AbstractSwaggerFeature.setResourcePackage(String) > --> > org.apache.cxf.common.util.PackageUtils.getSharedPackageName(List>) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7124) PackageUtils.getSharedPackageName(List>) has bug
[ https://issues.apache.org/jira/browse/CXF-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696124#comment-15696124 ] Neal Hu commented on CXF-7124: -- When I tried to push github returned: 23:30 Push failed: Failed with error: fatal: unable to access 'https://github.com/apache/cxf.git/': The requested URL returned error: 403 my github id is nbqyqx, how can i get the proper permission? by the way I have upload the new patch, please review. Thanks. > PackageUtils.getSharedPackageName(List>) has bug > - > > Key: CXF-7124 > URL: https://issues.apache.org/jira/browse/CXF-7124 > Project: CXF > Issue Type: Bug > Components: Core, JAX-RS >Affects Versions: 3.1.7 > Environment: mac swagger >Reporter: Neal Hu >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.9, 3.0.12 > > Attachments: Fix_the_bug_of_PackageUtils.patch, > org.apache.cxf.common.util.PackageUtils.patch, > org.apache.cxf.common.util.PackageUtilsTest.patch > > > The swagger feature scans undefined api, the root cause is the util in > PackageUtils has bug. For example: > String packageName = PackageUtils.getSharedPackageName( > Arrays.asList(org.apache.cxf.common.util.PackageUtils.class, > org.apache.cxf.bus.CXFBusFactory.class, > org.apache.cxf.common.jaxb.JAXBContextCache.class)); > Currently we get org.apache, but we should get org.apache.cxf. > I have uploaded the patch and verified in the local environment, please > review. > -- > org.apache.cxf.jaxrs.swagger.AbstractSwaggerFeature.setResourcePackage(String) > --> > org.apache.cxf.common.util.PackageUtils.getSharedPackageName(List>) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7124) PackageUtils.getSharedPackageName(List>) has bug
[ https://issues.apache.org/jira/browse/CXF-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696197#comment-15696197 ] Neal Hu commented on CXF-7124: -- I have committed the change, please review on https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=search;s=Neal+Hu;st=author Thanks > PackageUtils.getSharedPackageName(List>) has bug > - > > Key: CXF-7124 > URL: https://issues.apache.org/jira/browse/CXF-7124 > Project: CXF > Issue Type: Bug > Components: Core, JAX-RS >Affects Versions: 3.1.7 > Environment: mac swagger >Reporter: Neal Hu >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.9, 3.0.12 > > Attachments: Fix_the_bug_of_PackageUtils.patch, > org.apache.cxf.common.util.PackageUtils.patch, > org.apache.cxf.common.util.PackageUtilsTest.patch > > > The swagger feature scans undefined api, the root cause is the util in > PackageUtils has bug. For example: > String packageName = PackageUtils.getSharedPackageName( > Arrays.asList(org.apache.cxf.common.util.PackageUtils.class, > org.apache.cxf.bus.CXFBusFactory.class, > org.apache.cxf.common.jaxb.JAXBContextCache.class)); > Currently we get org.apache, but we should get org.apache.cxf. > I have uploaded the patch and verified in the local environment, please > review. > -- > org.apache.cxf.jaxrs.swagger.AbstractSwaggerFeature.setResourcePackage(String) > --> > org.apache.cxf.common.util.PackageUtils.getSharedPackageName(List>) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7124) PackageUtils.getSharedPackageName(List>) has bug
[ https://issues.apache.org/jira/browse/CXF-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696195#comment-15696195 ] Sergey Beryozkin commented on CXF-7124: --- Hi Neal, congrats on your first commits :-) > PackageUtils.getSharedPackageName(List>) has bug > - > > Key: CXF-7124 > URL: https://issues.apache.org/jira/browse/CXF-7124 > Project: CXF > Issue Type: Bug > Components: Core, JAX-RS >Affects Versions: 3.1.7 > Environment: mac swagger >Reporter: Neal Hu >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.9, 3.0.12 > > Attachments: Fix_the_bug_of_PackageUtils.patch, > org.apache.cxf.common.util.PackageUtils.patch, > org.apache.cxf.common.util.PackageUtilsTest.patch > > > The swagger feature scans undefined api, the root cause is the util in > PackageUtils has bug. For example: > String packageName = PackageUtils.getSharedPackageName( > Arrays.asList(org.apache.cxf.common.util.PackageUtils.class, > org.apache.cxf.bus.CXFBusFactory.class, > org.apache.cxf.common.jaxb.JAXBContextCache.class)); > Currently we get org.apache, but we should get org.apache.cxf. > I have uploaded the patch and verified in the local environment, please > review. > -- > org.apache.cxf.jaxrs.swagger.AbstractSwaggerFeature.setResourcePackage(String) > --> > org.apache.cxf.common.util.PackageUtils.getSharedPackageName(List>) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7124) PackageUtils.getSharedPackageName(List>) has bug
[ https://issues.apache.org/jira/browse/CXF-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696205#comment-15696205 ] Sergey Beryozkin commented on CXF-7124: --- Hi Neal, usually a bug fix does not require any discussions, unless the fix may prove to be sensitive, as with TCK related issues. And we can discuss various improvements/new feature on the dev list... thanks for committing this fix > PackageUtils.getSharedPackageName(List>) has bug > - > > Key: CXF-7124 > URL: https://issues.apache.org/jira/browse/CXF-7124 > Project: CXF > Issue Type: Bug > Components: Core, JAX-RS >Affects Versions: 3.1.7 > Environment: mac swagger >Reporter: Neal Hu >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.9, 3.0.12 > > Attachments: Fix_the_bug_of_PackageUtils.patch, > org.apache.cxf.common.util.PackageUtils.patch, > org.apache.cxf.common.util.PackageUtilsTest.patch > > > The swagger feature scans undefined api, the root cause is the util in > PackageUtils has bug. For example: > String packageName = PackageUtils.getSharedPackageName( > Arrays.asList(org.apache.cxf.common.util.PackageUtils.class, > org.apache.cxf.bus.CXFBusFactory.class, > org.apache.cxf.common.jaxb.JAXBContextCache.class)); > Currently we get org.apache, but we should get org.apache.cxf. > I have uploaded the patch and verified in the local environment, please > review. > -- > org.apache.cxf.jaxrs.swagger.AbstractSwaggerFeature.setResourcePackage(String) > --> > org.apache.cxf.common.util.PackageUtils.getSharedPackageName(List>) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7150) CXF Swagger2Feature does not work in karaf when use equinox as the osgi framework
[
https://issues.apache.org/jira/browse/CXF-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696241#comment-15696241
]
Sergey Beryozkin commented on CXF-7150:
---
I'm not sure if there's anything that Swagger2Feature itself can do - but
please try set a scan property to false.
> CXF Swagger2Feature does not work in karaf when use equinox as the osgi
> framework
> -
>
> Key: CXF-7150
> URL: https://issues.apache.org/jira/browse/CXF-7150
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.8
> Environment: karaf equinox
>Reporter: H.G Vantaking
>
> It got ReflectionsException in org.reflections.Reflections and the warnning
> {{could not create Vfs.Dir from url. ignoring the exception and continuing}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7119) Introduce a JAX-RS client provider for catching technical exceptions (e.g. IOException)
[
https://issues.apache.org/jira/browse/CXF-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696282#comment-15696282
]
Sergey Beryozkin commented on CXF-7119:
---
Both approaches give the user a full control but I agree the latter option is
less attractive for the proxy users.
But the other question is the consistency with respect to processing the
client technical exceptions for both Proxy and HTTP Centric JAX-RS clients
(JAX-RS 2.0 clients, CXF WebClient). HTTP centric clients will throw
ProcessingException and if Proxy throws ProcessingException (and this is
something the users may already have written the code around) the we can have:
{code:java}
MyProxy proxy = createProxy();
try {
useProxy(proxy);
} catch (ProcessingException ex) {
handleException(ex.getCause());
}
WebTarget web = createJAXRS20WebTarget();
try {
useWebTarget(web);
} catch (ProcessingException ex) {
handleException(ex.getCause());
}
// reused by the proxy and web target code
private void handleException(Throwable t) {
}
{code}
And as I already noted proxies have been wrapping the exceptions into
ProcessingException for a while so I can not change that by default.
But what I can do is to introduce a property which your fault in interceptors
can set and which will let the client code avoid wrapping the runtime
exceptions.
> Introduce a JAX-RS client provider for catching technical exceptions (e.g.
> IOException)
> ---
>
> Key: CXF-7119
> URL: https://issues.apache.org/jira/browse/CXF-7119
> Project: CXF
> Issue Type: New Feature
> Components: JAX-RS
>Affects Versions: 3.1.3
>Reporter: Jörg Hohwiller
>Assignee: Sergey Beryozkin
> Fix For: 3.2.0, 3.1.9
>
>
> When using CXF for REST/JAX-RS service clients I quickly noticed that I need
> to tweak the error handling. My services use an ExceptionMapper that provides
> error details via JSON result payload. Hence I want to access this and render
> an exception with further details and more context information what works
> fine with ResponseExceptionMapper.
> However, when a technical error (IOException such as unkown host, connection
> refused, timeout, etc.) occurrs I only get generic errors from CXF client
> (org.apache.cxf.interceptor.Fault: Could not send Message.). This is
> undesired but unfortunately my custom ResponseExceptionMapper is never called
> for such technical errors. There seems to be no way to archive my goal with
> CXF itself. I could only wrap the client again with a custom written dynamic
> proxy to reach my goal.
> It seems that CXF hardwires this behaviour:
> https://github.com/apache/cxf/blob/master/rt/rs/client/src/main/java/org/apache/cxf/jaxrs/client/AbstractClient.java#L596
> https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/interceptor/MessageSenderInterceptor.java#L64
> It would be awesome if in such case ResponseExceptionMapper would also be
> applied so I have the chance to interfere and produce better exceptions (e.g.
> with a message containing the name of the application/microservice that could
> not be called, the URL, etc.) for my individual needs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7119) Introduce a JAX-RS client provider for catching technical exceptions (e.g. IOException)
[ https://issues.apache.org/jira/browse/CXF-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696594#comment-15696594 ] Sergey Beryozkin commented on CXF-7119: --- OK, I've added a "wrap.in.processing.exception" property - set it on the current exchange in the FaultInInterceptor to false and you'll get your custom RuntimeExceptions representing the original IOExceptions caught at the top catch level. I don't mind reviewing the possibility of supporting it by default later on - for the moment we should expect other proxy users have already written a code around ProcessingException. > Introduce a JAX-RS client provider for catching technical exceptions (e.g. > IOException) > --- > > Key: CXF-7119 > URL: https://issues.apache.org/jira/browse/CXF-7119 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Affects Versions: 3.1.3 >Reporter: Jörg Hohwiller >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.9 > > > When using CXF for REST/JAX-RS service clients I quickly noticed that I need > to tweak the error handling. My services use an ExceptionMapper that provides > error details via JSON result payload. Hence I want to access this and render > an exception with further details and more context information what works > fine with ResponseExceptionMapper. > However, when a technical error (IOException such as unkown host, connection > refused, timeout, etc.) occurrs I only get generic errors from CXF client > (org.apache.cxf.interceptor.Fault: Could not send Message.). This is > undesired but unfortunately my custom ResponseExceptionMapper is never called > for such technical errors. There seems to be no way to archive my goal with > CXF itself. I could only wrap the client again with a custom written dynamic > proxy to reach my goal. > It seems that CXF hardwires this behaviour: > https://github.com/apache/cxf/blob/master/rt/rs/client/src/main/java/org/apache/cxf/jaxrs/client/AbstractClient.java#L596 > https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/interceptor/MessageSenderInterceptor.java#L64 > It would be awesome if in such case ResponseExceptionMapper would also be > applied so I have the chance to interfere and produce better exceptions (e.g. > with a message containing the name of the application/microservice that could > not be called, the URL, etc.) for my individual needs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-7137) Allow OAuth2 customization via Swagger2Feature
[ https://issues.apache.org/jira/browse/CXF-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin reassigned CXF-7137: - Assignee: Sergey Beryozkin Only committing to investigating it during the next week or so a this moment of time > 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. >Assignee: Sergey Beryozkin > > 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] [Created] (CXF-7151) Remove WS specific Policy In/Out interceptors from JAX-RS chains
Sergey Beryozkin created CXF-7151: - Summary: Remove WS specific Policy In/Out interceptors from JAX-RS chains Key: CXF-7151 URL: https://issues.apache.org/jira/browse/CXF-7151 Project: CXF Issue Type: Improvement Components: JAX-RS Reporter: Sergey Beryozkin Fix For: 3.2.0, 3.1.9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7152) OIDC FormResponse mode needs to be supported for Implicit Flow too
Sergey Beryozkin created CXF-7152: - Summary: OIDC FormResponse mode needs to be supported for Implicit Flow too Key: CXF-7152 URL: https://issues.apache.org/jira/browse/CXF-7152 Project: CXF Issue Type: Task Components: JAX-RS Security Reporter: Sergey Beryozkin Priority: Minor Fix For: 3.2.0, 3.1.9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-5663) IllegalStateException using AsyncHTTPConduit
[
https://issues.apache.org/jira/browse/CXF-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696820#comment-15696820
]
Sergey Beryozkin commented on CXF-5663:
---
[~ffang] Hi Freeman - may be you can have a look at this issue at some point of
time ?
> IllegalStateException using AsyncHTTPConduit
>
>
> Key: CXF-5663
> URL: https://issues.apache.org/jira/browse/CXF-5663
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 2.7.10
> Environment: SunOS 5.10 Generic_147440-25 sun4v sparc
> SUNW,SPARC-Enterprise-T5120, 64bit
>Reporter: Przemysław Ołtarzewski
>
> We are using CXF with Async HTTP Transport to call web services of another
> system. Every once in a while an attempt to send request ends in
> IllegalStateException - Buffer already closed for writing (logs provided
> below).
> {noformat}
> 2014.04.01 10:47:22.601
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$3 DEBUG
> [HLAPI-47] DefaultAsyncRequestDirector:208 [exchange: 5663] start execution
> 2014.04.01 10:47:22.601
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$3 DEBUG
> [HLAPI-47] DefaultAsyncRequestDirector:625 [exchange: 5663] Request
> connection for {}->http://10.250.32.140:8082
> 2014.04.01 10:47:22.602
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$2 DEBUG
> [HLAPI-47] PoolingClientAsyncConnectionManager:172 Connection request:
> [route: {}->http://10.250.32.140:8082][total kept alive: 2; route allocated:
> 2 of 1000; total allocated: 2 of 5000]
> 2014.04.01 10:47:22.603
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$2 DEBUG
> [HLAPI-47] PoolingClientAsyncConnectionManager$InternalPoolEntryCallback:297
> Connection leased: [id: 1746][route: {}->http://10.250.32.140:8082][total
> kept alive: 1; route allocated: 2 of 1000; total allocated: 2 of 5000]
> 2014.04.01 10:47:22.604
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$3 DEBUG
> [HLAPI-47] DefaultAsyncRequestDirector:558 [exchange: 5663] Connection
> allocated: [id:1746][route:{}->http://10.250.32.140:8082][state:null]
> 2014.04.01 10:47:22.625 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [I/O dispatcher 18] LoggingIOSession$LoggingByteChannel:189
> http-outgoing-1746 10.252.152.177:65127<->10.250.32.140:8082[ACTIVE][r:r]: -1
> bytes read
> 2014.04.01 10:47:22.625 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [HLAPI-47] LoggingIOSession:167 http-outgoing-1746
> 10.252.152.177:65127<->10.250.32.140:8082[ACTIVE][r:r]: Set attribute
> http.nio.exchange-handler
> 2014.04.01 10:47:22.626 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [I/O dispatcher 18] LoggingIOSession:118 http-outgoing-1746
> 10.252.152.177:65127<->10.250.32.140:8082[ACTIVE][r:r]: Close
> 2014.04.01 10:47:22.626 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [HLAPI-47] LoggingIOSession:105 http-outgoing-1746
> 10.252.152.177:65127<->10.250.32.140:8082[CLOSED][]: Event set [w]
> 2014.04.01 10:47:22.628
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$3 DEBUG
> [HLAPI-47] DefaultAsyncRequestDirector:185 [exchange: 5663] aborting
> connection [id:1746][route:{}->http://10.250.32.140:8082][state:null]
> 2014.04.01 10:47:22.629 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [HLAPI-47] LoggingIOSession:133 http-outgoing-1746 [CLOSED][]: Shutdown
> 2014.04.01 10:47:22.629 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [HLAPI-47] LoggingIOSession:133 http-outgoing-1746 [CLOSED][]: Shutdown
> 2014.04.01 10:47:22.630
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$2 DEBUG
> [HLAPI-47] PoolingClientAsyncConnectionManager:236 Connection released: [id:
> 1746][route: {}->http://10.250.32.140:8082][total kept alive: 1; route
> allocated: 1 of 1000; total allocated: 1 of 5000]
> 2014.04.01 10:47:22.642 org.apache.cxf.phase.PhaseInterceptorChain WARN
> [HLAPI-47] LogUtils:452 Interceptor for
> {http://implementation.web.api.icc.services.osp.in.alcatel.com}SubscriberLineManagerPortTypeService#{http://implementation.web.api.icc.services.osp.in.alcatel.com}getAll
> has thrown exception, unwinding now
> java.lang.IllegalStateException: IllegalStateException invoking
> http://10.250.32.140:8082/HighLevelApiWS-2.4/services/SubscriberLineManager:
> Buffer already closed for writing
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>
[jira] [Assigned] (CXF-5663) IllegalStateException using AsyncHTTPConduit
[
https://issues.apache.org/jira/browse/CXF-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-5663:
-
Assignee: Freeman Fang
> IllegalStateException using AsyncHTTPConduit
>
>
> Key: CXF-5663
> URL: https://issues.apache.org/jira/browse/CXF-5663
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 2.7.10
> Environment: SunOS 5.10 Generic_147440-25 sun4v sparc
> SUNW,SPARC-Enterprise-T5120, 64bit
>Reporter: Przemysław Ołtarzewski
>Assignee: Freeman Fang
>
> We are using CXF with Async HTTP Transport to call web services of another
> system. Every once in a while an attempt to send request ends in
> IllegalStateException - Buffer already closed for writing (logs provided
> below).
> {noformat}
> 2014.04.01 10:47:22.601
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$3 DEBUG
> [HLAPI-47] DefaultAsyncRequestDirector:208 [exchange: 5663] start execution
> 2014.04.01 10:47:22.601
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$3 DEBUG
> [HLAPI-47] DefaultAsyncRequestDirector:625 [exchange: 5663] Request
> connection for {}->http://10.250.32.140:8082
> 2014.04.01 10:47:22.602
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$2 DEBUG
> [HLAPI-47] PoolingClientAsyncConnectionManager:172 Connection request:
> [route: {}->http://10.250.32.140:8082][total kept alive: 2; route allocated:
> 2 of 1000; total allocated: 2 of 5000]
> 2014.04.01 10:47:22.603
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$2 DEBUG
> [HLAPI-47] PoolingClientAsyncConnectionManager$InternalPoolEntryCallback:297
> Connection leased: [id: 1746][route: {}->http://10.250.32.140:8082][total
> kept alive: 1; route allocated: 2 of 1000; total allocated: 2 of 5000]
> 2014.04.01 10:47:22.604
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$3 DEBUG
> [HLAPI-47] DefaultAsyncRequestDirector:558 [exchange: 5663] Connection
> allocated: [id:1746][route:{}->http://10.250.32.140:8082][state:null]
> 2014.04.01 10:47:22.625 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [I/O dispatcher 18] LoggingIOSession$LoggingByteChannel:189
> http-outgoing-1746 10.252.152.177:65127<->10.250.32.140:8082[ACTIVE][r:r]: -1
> bytes read
> 2014.04.01 10:47:22.625 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [HLAPI-47] LoggingIOSession:167 http-outgoing-1746
> 10.252.152.177:65127<->10.250.32.140:8082[ACTIVE][r:r]: Set attribute
> http.nio.exchange-handler
> 2014.04.01 10:47:22.626 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [I/O dispatcher 18] LoggingIOSession:118 http-outgoing-1746
> 10.252.152.177:65127<->10.250.32.140:8082[ACTIVE][r:r]: Close
> 2014.04.01 10:47:22.626 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [HLAPI-47] LoggingIOSession:105 http-outgoing-1746
> 10.252.152.177:65127<->10.250.32.140:8082[CLOSED][]: Event set [w]
> 2014.04.01 10:47:22.628
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$3 DEBUG
> [HLAPI-47] DefaultAsyncRequestDirector:185 [exchange: 5663] aborting
> connection [id:1746][route:{}->http://10.250.32.140:8082][state:null]
> 2014.04.01 10:47:22.629 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [HLAPI-47] LoggingIOSession:133 http-outgoing-1746 [CLOSED][]: Shutdown
> 2014.04.01 10:47:22.629 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [HLAPI-47] LoggingIOSession:133 http-outgoing-1746 [CLOSED][]: Shutdown
> 2014.04.01 10:47:22.630
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$2 DEBUG
> [HLAPI-47] PoolingClientAsyncConnectionManager:236 Connection released: [id:
> 1746][route: {}->http://10.250.32.140:8082][total kept alive: 1; route
> allocated: 1 of 1000; total allocated: 1 of 5000]
> 2014.04.01 10:47:22.642 org.apache.cxf.phase.PhaseInterceptorChain WARN
> [HLAPI-47] LogUtils:452 Interceptor for
> {http://implementation.web.api.icc.services.osp.in.alcatel.com}SubscriberLineManagerPortTypeService#{http://implementation.web.api.icc.services.osp.in.alcatel.com}getAll
> has thrown exception, unwinding now
> java.lang.IllegalStateException: IllegalStateException invoking
> http://10.250.32.140:8082/HighLevelApiWS-2.4/services/SubscriberLineManager:
> Buffer already closed for writing
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(H
[jira] [Commented] (CXF-5663) IllegalStateException using AsyncHTTPConduit
[
https://issues.apache.org/jira/browse/CXF-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696838#comment-15696838
]
Freeman Fang commented on CXF-5663:
---
Hi Sergey,
Sure, I will take a close look when I get chance.
Cheers
Freeman
> IllegalStateException using AsyncHTTPConduit
>
>
> Key: CXF-5663
> URL: https://issues.apache.org/jira/browse/CXF-5663
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 2.7.10
> Environment: SunOS 5.10 Generic_147440-25 sun4v sparc
> SUNW,SPARC-Enterprise-T5120, 64bit
>Reporter: Przemysław Ołtarzewski
>
> We are using CXF with Async HTTP Transport to call web services of another
> system. Every once in a while an attempt to send request ends in
> IllegalStateException - Buffer already closed for writing (logs provided
> below).
> {noformat}
> 2014.04.01 10:47:22.601
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$3 DEBUG
> [HLAPI-47] DefaultAsyncRequestDirector:208 [exchange: 5663] start execution
> 2014.04.01 10:47:22.601
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$3 DEBUG
> [HLAPI-47] DefaultAsyncRequestDirector:625 [exchange: 5663] Request
> connection for {}->http://10.250.32.140:8082
> 2014.04.01 10:47:22.602
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$2 DEBUG
> [HLAPI-47] PoolingClientAsyncConnectionManager:172 Connection request:
> [route: {}->http://10.250.32.140:8082][total kept alive: 2; route allocated:
> 2 of 1000; total allocated: 2 of 5000]
> 2014.04.01 10:47:22.603
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$2 DEBUG
> [HLAPI-47] PoolingClientAsyncConnectionManager$InternalPoolEntryCallback:297
> Connection leased: [id: 1746][route: {}->http://10.250.32.140:8082][total
> kept alive: 1; route allocated: 2 of 1000; total allocated: 2 of 5000]
> 2014.04.01 10:47:22.604
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$3 DEBUG
> [HLAPI-47] DefaultAsyncRequestDirector:558 [exchange: 5663] Connection
> allocated: [id:1746][route:{}->http://10.250.32.140:8082][state:null]
> 2014.04.01 10:47:22.625 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [I/O dispatcher 18] LoggingIOSession$LoggingByteChannel:189
> http-outgoing-1746 10.252.152.177:65127<->10.250.32.140:8082[ACTIVE][r:r]: -1
> bytes read
> 2014.04.01 10:47:22.625 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [HLAPI-47] LoggingIOSession:167 http-outgoing-1746
> 10.252.152.177:65127<->10.250.32.140:8082[ACTIVE][r:r]: Set attribute
> http.nio.exchange-handler
> 2014.04.01 10:47:22.626 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [I/O dispatcher 18] LoggingIOSession:118 http-outgoing-1746
> 10.252.152.177:65127<->10.250.32.140:8082[ACTIVE][r:r]: Close
> 2014.04.01 10:47:22.626 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [HLAPI-47] LoggingIOSession:105 http-outgoing-1746
> 10.252.152.177:65127<->10.250.32.140:8082[CLOSED][]: Event set [w]
> 2014.04.01 10:47:22.628
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$3 DEBUG
> [HLAPI-47] DefaultAsyncRequestDirector:185 [exchange: 5663] aborting
> connection [id:1746][route:{}->http://10.250.32.140:8082][state:null]
> 2014.04.01 10:47:22.629 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [HLAPI-47] LoggingIOSession:133 http-outgoing-1746 [CLOSED][]: Shutdown
> 2014.04.01 10:47:22.629 org.apache.http.impl.nio.reactor.IOSessionImpl DEBUG
> [HLAPI-47] LoggingIOSession:133 http-outgoing-1746 [CLOSED][]: Shutdown
> 2014.04.01 10:47:22.630
> org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduitFactory$2 DEBUG
> [HLAPI-47] PoolingClientAsyncConnectionManager:236 Connection released: [id:
> 1746][route: {}->http://10.250.32.140:8082][total kept alive: 1; route
> allocated: 1 of 1000; total allocated: 1 of 5000]
> 2014.04.01 10:47:22.642 org.apache.cxf.phase.PhaseInterceptorChain WARN
> [HLAPI-47] LogUtils:452 Interceptor for
> {http://implementation.web.api.icc.services.osp.in.alcatel.com}SubscriberLineManagerPortTypeService#{http://implementation.web.api.icc.services.osp.in.alcatel.com}getAll
> has thrown exception, unwinding now
> java.lang.IllegalStateException: IllegalStateException invoking
> http://10.250.32.140:8082/HighLevelApiWS-2.4/services/SubscriberLineManager:
> Buffer already closed for writing
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache
[jira] [Commented] (CXF-7150) CXF Swagger2Feature does not work in karaf when use equinox as the osgi framework
[
https://issues.apache.org/jira/browse/CXF-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15697258#comment-15697258
]
H.G Vantaking commented on CXF-7150:
yes when set scan property to false it works
> CXF Swagger2Feature does not work in karaf when use equinox as the osgi
> framework
> -
>
> Key: CXF-7150
> URL: https://issues.apache.org/jira/browse/CXF-7150
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.8
> Environment: karaf equinox
>Reporter: H.G Vantaking
>
> It got ReflectionsException in org.reflections.Reflections and the warnning
> {{could not create Vfs.Dir from url. ignoring the exception and continuing}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CXF-7150) CXF Swagger2Feature does not work in karaf when use equinox as the osgi framework
[
https://issues.apache.org/jira/browse/CXF-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
H.G Vantaking closed CXF-7150.
--
Resolution: Not A Problem
Fix Version/s: 3.1.8
need to set scan property to false
> CXF Swagger2Feature does not work in karaf when use equinox as the osgi
> framework
> -
>
> Key: CXF-7150
> URL: https://issues.apache.org/jira/browse/CXF-7150
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.8
> Environment: karaf equinox
>Reporter: H.G Vantaking
> Fix For: 3.1.8
>
>
> It got ReflectionsException in org.reflections.Reflections and the warnning
> {{could not create Vfs.Dir from url. ignoring the exception and continuing}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CXF-7150) CXF Swagger2Feature does not work in karaf when use equinox as the osgi framework
[
https://issues.apache.org/jira/browse/CXF-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
H.G Vantaking updated CXF-7150:
---
Comment: was deleted
(was: need to set scan property to false)
> CXF Swagger2Feature does not work in karaf when use equinox as the osgi
> framework
> -
>
> Key: CXF-7150
> URL: https://issues.apache.org/jira/browse/CXF-7150
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.8
> Environment: karaf equinox
>Reporter: H.G Vantaking
> Fix For: 3.1.8
>
>
> It got ReflectionsException in org.reflections.Reflections and the warnning
> {{could not create Vfs.Dir from url. ignoring the exception and continuing}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
