[jira] [Updated] (CXF-7119) ResponseExceptionMapper not used for technical exceptions (e.g. IOException)
[ https://issues.apache.org/jira/browse/CXF-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Hohwiller updated CXF-7119: Affects Version/s: 3.1.3 > ResponseExceptionMapper not used for technical exceptions (e.g. IOException) > > > Key: CXF-7119 > URL: https://issues.apache.org/jira/browse/CXF-7119 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.3 >Reporter: Jörg Hohwiller > > 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] [Created] (CXF-7119) ResponseExceptionMapper not used for technical exceptions (e.g. IOException)
Jörg Hohwiller created CXF-7119: --- Summary: ResponseExceptionMapper not used for technical exceptions (e.g. IOException) Key: CXF-7119 URL: https://issues.apache.org/jira/browse/CXF-7119 Project: CXF Issue Type: Bug Components: JAX-RS Reporter: Jörg Hohwiller 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-7023) SOAP over JMS transport does not use XA transactions with Websphere MQ resource adapter
[ https://issues.apache.org/jira/browse/CXF-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned CXF-7023: Assignee: Christian Schneider > SOAP over JMS transport does not use XA transactions with Websphere MQ > resource adapter > --- > > Key: CXF-7023 > URL: https://issues.apache.org/jira/browse/CXF-7023 > Project: CXF > Issue Type: Bug > Components: JMS >Affects Versions: 3.1.7 >Reporter: Nikolay Boklaschuk >Assignee: Christian Schneider > > When using Websphere MQ resource adapter > Inbound one-way service does not uses XA transactions. > This is because WMQ adapter decides to use XA transaction when creates jms > connection, but connection opened in JMSDestination, and transaction started > in PollingMessageListnerContainer after connection created. > Futhermore WMQ adapter holds only one session per connection. > I have patched XAPoller to hold connection for each thread, it works, but may > be there are better way to provide support for WMQ adapter? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7115) Issuer in TokenIntrospection should be quoted in JSON
[ https://issues.apache.org/jira/browse/CXF-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15625423#comment-15625423 ] Sergey Beryozkin commented on CXF-7115: --- Thanks for spotting it, it was a copy and paste issue. FYI, ATs can be now represented as JWTs by the default Ehcache/JCache providers which may offer an option to validate them locally at the RS side > Issuer in TokenIntrospection should be quoted in JSON > - > > Key: CXF-7115 > URL: https://issues.apache.org/jira/browse/CXF-7115 > Project: CXF > Issue Type: Bug > Components: JAX-RS Security >Affects Versions: 3.1.8 >Reporter: Svein Otto Solem >Assignee: Sergey Beryozkin >Priority: Trivial > Fix For: 3.2.0, 3.1.9 > > > See line 118 in OauthJSONProvider : > appendJsonPair(sb, "iss", obj.getIss(), false); > it should be > appendJsonPair(sb, "iss", obj.getIss(), true ); > in my opinion since the issuer typically is a uri. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7116) AsyncResponse.resume() infinitely hangs up after first call
[
https://issues.apache.org/jira/browse/CXF-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15625954#comment-15625954
]
Sergey Beryozkin commented on CXF-7116:
---
Thanks for providing the test project. I've confirmed it only affects the
service code which was created with the embedded Jetty transport, using the
code like this one (with the jetty-webapp dep) works:
{code:java}
org.eclipse.jetty.server.Server server = new
org.eclipse.jetty.server.Server(port);
final ServletHolder servletHolder = new ServletHolder(new
CXFNonSpringJaxrsServlet());
final ServletContextHandler context = new ServletContextHandler();
context.setContextPath("/");
context.addServlet(servletHolder, "/*");
servletHolder.setInitParameter("jaxrs.serviceClasses",
SimpleResource.class.getName());
server.setHandler(context);
server.start();
// invoke
server.stop();
{code}
Apparently this failure has been caused by removing the synchronized blocks
(CXF-7037), looks like adding a 'synchronized' qualifier to
AsyncResponseImpl.suspendContinuationIfNeeded only fixes this issue.
> AsyncResponse.resume() infinitely hangs up after first call
> ---
>
> Key: CXF-7116
> URL: https://issues.apache.org/jira/browse/CXF-7116
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.8
> Environment: * Java - 1.8.0_66 (build 1.8.0_66-b17)
> * CXF - 3.1.8
> * Jetty - 9.3.13.v20161014
> * OS - OS X El Capitan 10.11.6
>Reporter: Dmytro Khrystiuk
> Labels: async
> Attachments: cxf-issue.zip
>
>
> Issue with AsyncResponse happened after upgrade from CXF 3.1.7 to 3.1.8.
> After the second call to REST method server stops to respond. Implementation
> of method uses AsyncResponse and call to resume() in a separate thread:
> @GET
> @Produces(MediaType.TEXT_PLAIN)
> @Path("/doesNotWork")
> public void doesNotWork(@Suspended AsyncResponse response) {
> executorService.submit(() -> {
> LOGGER.debug("Async task...");
> response.resume("Success!");
> });
> }
> First call to method above works as it should but subsequent calls just hangs
> up forever. No thread deadlocks were detected.
> The example test (Maven project) is attached to this item.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7116) AsyncResponse.resume() infinitely hangs up after first call
[
https://issues.apache.org/jira/browse/CXF-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15626016#comment-15626016
]
Sergey Beryozkin commented on CXF-7116:
---
Though I can not reproduce it with the CXF tests
> AsyncResponse.resume() infinitely hangs up after first call
> ---
>
> Key: CXF-7116
> URL: https://issues.apache.org/jira/browse/CXF-7116
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.8
> Environment: * Java - 1.8.0_66 (build 1.8.0_66-b17)
> * CXF - 3.1.8
> * Jetty - 9.3.13.v20161014
> * OS - OS X El Capitan 10.11.6
>Reporter: Dmytro Khrystiuk
> Labels: async
> Attachments: cxf-issue.zip
>
>
> Issue with AsyncResponse happened after upgrade from CXF 3.1.7 to 3.1.8.
> After the second call to REST method server stops to respond. Implementation
> of method uses AsyncResponse and call to resume() in a separate thread:
> @GET
> @Produces(MediaType.TEXT_PLAIN)
> @Path("/doesNotWork")
> public void doesNotWork(@Suspended AsyncResponse response) {
> executorService.submit(() -> {
> LOGGER.debug("Async task...");
> response.resume("Success!");
> });
> }
> First call to method above works as it should but subsequent calls just hangs
> up forever. No thread deadlocks were detected.
> The example test (Maven project) is attached to this item.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7120) Can CXF REST sync and async WS compatible with JavaScript client?
Colbert Philippe created CXF-7120: - Summary: Can CXF REST sync and async WS compatible with JavaScript client? Key: CXF-7120 URL: https://issues.apache.org/jira/browse/CXF-7120 Project: CXF Issue Type: Wish Components: JAX-RS Reporter: Colbert Philippe Priority: Critical When writing a real web application the client is likely going to be written in JavaScript in a web-browser and if the server uses CXF then it's in Java. I think it's the case for a vast majority of CXF users. 1) QUESTION: Can we write a synchronous web service using CXF JAX-RS (REST) in Java and invoke it from JavaScript? Are there any features that are not supported by JavaScript? 2) QUESTION: Can we write an asynchronous web service using CXF JAX-RS (REST) in Java and invoke it from JavaScript? Are there any features that are not supported by JavaScript? I think many of us would appreciate a chapter in the documentation that talks about scenarios when using different languages as clients, JavaScript is one, but the client could as well be in Python, Ruby, Perl.You should recommend frameworks from other languages that have been tested to work with CXF. Please, cover both the synchronous and asynchronous case. A compatibility table should be given to out all client frameworks that have been tested to work with CXF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7116) AsyncResponse.resume() infinitely hangs up after first call
[
https://issues.apache.org/jira/browse/CXF-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15626235#comment-15626235
]
Dmytro Khrystiuk commented on CXF-7116:
---
Yes, you're right that such behaviour is reproducible only in case of using
embedded jetty transport.
Regarding reproducing in tests, it's important that calls to service during
test are inside loop. In case when we're executing only single call to service
without subsequent one all is working fine. So such behaviour appears only in
case of subsequent calls to async method.
> AsyncResponse.resume() infinitely hangs up after first call
> ---
>
> Key: CXF-7116
> URL: https://issues.apache.org/jira/browse/CXF-7116
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.8
> Environment: * Java - 1.8.0_66 (build 1.8.0_66-b17)
> * CXF - 3.1.8
> * Jetty - 9.3.13.v20161014
> * OS - OS X El Capitan 10.11.6
>Reporter: Dmytro Khrystiuk
> Labels: async
> Attachments: cxf-issue.zip
>
>
> Issue with AsyncResponse happened after upgrade from CXF 3.1.7 to 3.1.8.
> After the second call to REST method server stops to respond. Implementation
> of method uses AsyncResponse and call to resume() in a separate thread:
> @GET
> @Produces(MediaType.TEXT_PLAIN)
> @Path("/doesNotWork")
> public void doesNotWork(@Suspended AsyncResponse response) {
> executorService.submit(() -> {
> LOGGER.debug("Async task...");
> response.resume("Success!");
> });
> }
> First call to method above works as it should but subsequent calls just hangs
> up forever. No thread deadlocks were detected.
> The example test (Maven project) is attached to this item.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6782) Modifications to JAX-WS client request context leak the thread scope
[
https://issues.apache.org/jira/browse/CXF-6782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616679#comment-15616679
]
RANADEEP SHARMA edited comment on CXF-6782 at 11/1/16 7:39 PM:
---
Same issue is reproducible with CXF version 3.1.6 too.
The said method in ClientImpl.java code for CXF version 3.1.8 has change
either. Do we have any ETA when this would be fixed and in which version?
Most important - Could someone suggest a workaround to ensure the thread local
feature works as expected? Say, a way to override ClientImpl.java with
following method customization, where a new ConcurrentHashMap is instantiated.
public Map getRequestContext() {
if (isThreadLocalRequestContext()) {
if (!requestContext.containsKey(Thread.currentThread())) {
Map freshRequestContext = new
ConcurrentHashMap(8, 0.75f, 4);
requestContext.put(Thread.currentThread(), new
EchoContext(freshRequestContext));
}
return requestContext.get(Thread.currentThread());
}
return currentRequestContext;
}
was (Author: ranadeep.sha...@gmail.com):
Same issue is reproducible with CXF version 3.1.6 too.
> Modifications to JAX-WS client request context leak the thread scope
>
>
> Key: CXF-6782
> URL: https://issues.apache.org/jira/browse/CXF-6782
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.7
> Environment: java version "1.7.0_80"
>Reporter: Iacopo Rozzo
> Attachments: CXF-6782_reproducer.tar.gz
>
>
> As documented in
> [this|https://cxf.apache.org/faq.html#FAQ-AreJAX-WSclientproxiesthreadsafe?]
> page the request context can be made thread local (??Thus, anything set there
> will affect requests on other threads.??), but
> I observed that even after having set the property
> _thread.local.request.context_ it arrives sometimes that some modifications
> to the request context leak the thread scope, leading potentially to
> unpredictable behaviors.
> Digging in the code I found that the reason is the following.
> The class _org.apache.cxf.endpoint.ClientImpl_ stores the request context
> entries in a map called _currentRequestContext_. After property
> _thread.local.request.context_ is set to true a call to _getRequestContext()_
> triggers the creation of another map of type
> _org.apache.cxf.endpoint.ClientImpl.EchoContext_ which is associated to the
> current thread (the mapping is kept in the _requestContext_ map). This should
> guarantee the per thread isolation.
> The _EchoContext_ is initialized with the entries of the shared map, and as
> its name suggests modifications are echoed back to the shared map. The
> problem is that when accessing the request context for the first time in a
> thread all the modifications done on other threads do affect the current
> thread even after "thread.local.request.context" is set to true, due to the
> initialization of the thread local map with shared one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6782) Modifications to JAX-WS client request context leak the thread scope
[
https://issues.apache.org/jira/browse/CXF-6782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15616679#comment-15616679
]
RANADEEP SHARMA edited comment on CXF-6782 at 11/1/16 7:40 PM:
---
Same issue is reproducible with CXF version 3.1.6 too.
The said method in ClientImpl.java code for CXF version 3.1.8 has NOT change
either. Do we have any ETA when this would be fixed and in which version?
Most important - Could someone suggest a workaround to ensure the thread local
feature works as expected? Say, a way to override ClientImpl.java with
following method customization, where a new ConcurrentHashMap is instantiated.
public Map getRequestContext() {
if (isThreadLocalRequestContext()) {
if (!requestContext.containsKey(Thread.currentThread())) {
Map freshRequestContext = new
ConcurrentHashMap(8, 0.75f, 4);
requestContext.put(Thread.currentThread(), new
EchoContext(freshRequestContext));
}
return requestContext.get(Thread.currentThread());
}
return currentRequestContext;
}
was (Author: ranadeep.sha...@gmail.com):
Same issue is reproducible with CXF version 3.1.6 too.
The said method in ClientImpl.java code for CXF version 3.1.8 has change
either. Do we have any ETA when this would be fixed and in which version?
Most important - Could someone suggest a workaround to ensure the thread local
feature works as expected? Say, a way to override ClientImpl.java with
following method customization, where a new ConcurrentHashMap is instantiated.
public Map getRequestContext() {
if (isThreadLocalRequestContext()) {
if (!requestContext.containsKey(Thread.currentThread())) {
Map freshRequestContext = new
ConcurrentHashMap(8, 0.75f, 4);
requestContext.put(Thread.currentThread(), new
EchoContext(freshRequestContext));
}
return requestContext.get(Thread.currentThread());
}
return currentRequestContext;
}
> Modifications to JAX-WS client request context leak the thread scope
>
>
> Key: CXF-6782
> URL: https://issues.apache.org/jira/browse/CXF-6782
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.7
> Environment: java version "1.7.0_80"
>Reporter: Iacopo Rozzo
> Attachments: CXF-6782_reproducer.tar.gz
>
>
> As documented in
> [this|https://cxf.apache.org/faq.html#FAQ-AreJAX-WSclientproxiesthreadsafe?]
> page the request context can be made thread local (??Thus, anything set there
> will affect requests on other threads.??), but
> I observed that even after having set the property
> _thread.local.request.context_ it arrives sometimes that some modifications
> to the request context leak the thread scope, leading potentially to
> unpredictable behaviors.
> Digging in the code I found that the reason is the following.
> The class _org.apache.cxf.endpoint.ClientImpl_ stores the request context
> entries in a map called _currentRequestContext_. After property
> _thread.local.request.context_ is set to true a call to _getRequestContext()_
> triggers the creation of another map of type
> _org.apache.cxf.endpoint.ClientImpl.EchoContext_ which is associated to the
> current thread (the mapping is kept in the _requestContext_ map). This should
> guarantee the per thread isolation.
> The _EchoContext_ is initialized with the entries of the shared map, and as
> its name suggests modifications are echoed back to the shared map. The
> problem is that when accessing the request context for the first time in a
> thread all the modifications done on other threads do affect the current
> thread even after "thread.local.request.context" is set to true, due to the
> initialization of the thread local map with shared one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7121) Need to log a warning when async method returns a non-void type
Andy McCright created CXF-7121: -- Summary: Need to log a warning when async method returns a non-void type Key: CXF-7121 URL: https://issues.apache.org/jira/browse/CXF-7121 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.1.8, 3.1.7 Reporter: Andy McCright Priority: Minor Fix For: 3.2.0, 3.1.9 According to the javadoc for the @Suspended annotation ( http://docs.oracle.com/javaee/7/api/javax/ws/rs/container/Suspended.html ), the JAX-RS runtime should be logging a warning message when a user's resource contains an async method (method with a @Suspended-annotated parameter) that returns a non-void type. Currently, CXF will log a FINE trace message, but it ought to be a WARNING so that it highlighted in the log output under normal logging settings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7121) Need to log a warning when async method returns a non-void type
[ https://issues.apache.org/jira/browse/CXF-7121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15626953#comment-15626953 ] ASF GitHub Bot commented on CXF-7121: - GitHub user andymc12 opened a pull request: https://github.com/apache/cxf/pull/189 CXF-7121 - log a warning when an async method returns a non-void type You can merge this pull request into a Git repository by running: $ git pull https://github.com/andymc12/cxf master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/189.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 #189 commit 25aa09fe52180beb183bae3cdc18d7eb9f6807cb Author: Andy McCright Date: 2016-10-03T16:30:24Z Merge pull request #1 from apache/master updating to master commit 6e5efebdff68804a4fc4faf39d4b116aa0444efe Author: Andy McCright Date: 2016-10-12T14:39:13Z Merge pull request #2 from apache/master update to latest commit 8235e6a6963f34a08632241c0811d4bcd262a854 Author: andymc12 Date: 2016-10-13T18:57:50Z Merge remote branch 'upstream/master' commit 8c5db1267f4cdb30270145eb8cd348d7b61105f2 Author: andymc12 Date: 2016-11-01T22:48:00Z CXF-7121 - log a warning when an async method returns a non-void type commit 586e29d0659aac31329c00dcb5aa5f1b354a4020 Author: Andy McCright Date: 2016-11-01T22:56:02Z Merge pull request #3 from andymc12/perf CXF-7121 - log a warning when an async method returns a non-void type > Need to log a warning when async method returns a non-void type > --- > > Key: CXF-7121 > URL: https://issues.apache.org/jira/browse/CXF-7121 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.7, 3.1.8 >Reporter: Andy McCright >Priority: Minor > Fix For: 3.2.0, 3.1.9 > > > According to the javadoc for the @Suspended annotation ( > http://docs.oracle.com/javaee/7/api/javax/ws/rs/container/Suspended.html ), > the JAX-RS runtime should be logging a warning message when a user's resource > contains an async method (method with a @Suspended-annotated parameter) that > returns a non-void type. > Currently, CXF will log a FINE trace message, but it ought to be a WARNING so > that it highlighted in the log output under normal logging settings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
