[jira] [Commented] (CXF-4496) find of ResponseExceptionMapper do not handle runtime exceptions
[
https://issues.apache.org/jira/browse/CXF-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464573#comment-13464573
]
Sergey Beryozkin commented on CXF-4496:
---
The client runtime guarantees (unless some bug is there) that it will throw
ClientException (JAX-RS 2.0) or ServerWebApplicationExxception representing the
remote service failure. To be honest I have doubts ResponseExceptionMapper has
to be checked when proxies have no exception classes in the signature, however,
at the same time, I guess proxies should be given a chance to 'pre-process'
unchecked exceptions.
If you have a catch statement expecting RuntimeException, then with
ResponseExceptionMapper (assuming it is CXF 2.7.0) the catch
will work. However I also think that a catch expecting ClientException should
also work, *irrespectively* of whether one has ResponseExceptionMapper or not.
> find of ResponseExceptionMapper do not handle runtime exceptions
>
>
> Key: CXF-4496
> URL: https://issues.apache.org/jira/browse/CXF-4496
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.6.2
>Reporter: n0rad
>Priority: Minor
>
> In org.apache.cxf.jaxrs.client.ClientProxyImpl.findExceptionMapper(Method,
> Message)
> The responseExceptionMapper is selected based on exception defined in the
> resource method signature but this method may have thrown a RuntimeException :
> {code:java}
> @Path("/")
> public interface RestMcuBoardResource {
> @GET
> public RestMcuBoard getBoard();
> }
> {code}
> does not work where this one work
> {code:java}
> @Path("/")
> public interface RestMcuBoardResource {
> @GET
> public RestMcuBoard getBoard() throws runtimeException;
> }
> {code}
> a fix could be :
> {code:java}
> private static ResponseExceptionMapper findExceptionMapper(Method m,
> Message message) {
> ProviderFactory pf = ProviderFactory.getInstance(message);
> for (Class exType : m.getExceptionTypes()) {
> ResponseExceptionMapper mapper =
> pf.createResponseExceptionMapper(exType);
> if (mapper != null) {
> return mapper;
> }
> }
> +return pf.createResponseExceptionMapper(RuntimeException.class);
> -return null;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4496) find of ResponseExceptionMapper do not handle runtime exceptions
[
https://issues.apache.org/jira/browse/CXF-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464579#comment-13464579
]
Sergey Beryozkin commented on CXF-4496:
---
I meant ClientErrorException (in case of JAX-RS 2.0):
http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/ClientErrorException.html,
it has a constructor which accepts a status code and Throwable - the latter
will be available at the RuntimeException mapper
> find of ResponseExceptionMapper do not handle runtime exceptions
>
>
> Key: CXF-4496
> URL: https://issues.apache.org/jira/browse/CXF-4496
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.6.2
>Reporter: n0rad
>Priority: Minor
>
> In org.apache.cxf.jaxrs.client.ClientProxyImpl.findExceptionMapper(Method,
> Message)
> The responseExceptionMapper is selected based on exception defined in the
> resource method signature but this method may have thrown a RuntimeException :
> {code:java}
> @Path("/")
> public interface RestMcuBoardResource {
> @GET
> public RestMcuBoard getBoard();
> }
> {code}
> does not work where this one work
> {code:java}
> @Path("/")
> public interface RestMcuBoardResource {
> @GET
> public RestMcuBoard getBoard() throws runtimeException;
> }
> {code}
> a fix could be :
> {code:java}
> private static ResponseExceptionMapper findExceptionMapper(Method m,
> Message message) {
> ProviderFactory pf = ProviderFactory.getInstance(message);
> for (Class exType : m.getExceptionTypes()) {
> ResponseExceptionMapper mapper =
> pf.createResponseExceptionMapper(exType);
> if (mapper != null) {
> return mapper;
> }
> }
> +return pf.createResponseExceptionMapper(RuntimeException.class);
> -return null;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CXF-4496) find of ResponseExceptionMapper do not handle runtime exceptions
[
https://issues.apache.org/jira/browse/CXF-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464579#comment-13464579
]
Sergey Beryozkin edited comment on CXF-4496 at 9/27/12 8:35 PM:
I meant ClientErrorException (in case of JAX-RS 2.0):
http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/ClientErrorException.html,
it has a constructor which accepts a status code and Throwable - the latter
will be available at the RuntimeException catch block
was (Author: sergey_beryozkin):
I meant ClientErrorException (in case of JAX-RS 2.0):
http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/ClientErrorException.html,
it has a constructor which accepts a status code and Throwable - the latter
will be available at the RuntimeException mapper
> find of ResponseExceptionMapper do not handle runtime exceptions
>
>
> Key: CXF-4496
> URL: https://issues.apache.org/jira/browse/CXF-4496
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 2.6.2
>Reporter: n0rad
>Priority: Minor
>
> In org.apache.cxf.jaxrs.client.ClientProxyImpl.findExceptionMapper(Method,
> Message)
> The responseExceptionMapper is selected based on exception defined in the
> resource method signature but this method may have thrown a RuntimeException :
> {code:java}
> @Path("/")
> public interface RestMcuBoardResource {
> @GET
> public RestMcuBoard getBoard();
> }
> {code}
> does not work where this one work
> {code:java}
> @Path("/")
> public interface RestMcuBoardResource {
> @GET
> public RestMcuBoard getBoard() throws runtimeException;
> }
> {code}
> a fix could be :
> {code:java}
> private static ResponseExceptionMapper findExceptionMapper(Method m,
> Message message) {
> ProviderFactory pf = ProviderFactory.getInstance(message);
> for (Class exType : m.getExceptionTypes()) {
> ResponseExceptionMapper mapper =
> pf.createResponseExceptionMapper(exType);
> if (mapper != null) {
> return mapper;
> }
> }
> +return pf.createResponseExceptionMapper(RuntimeException.class);
> -return null;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4523) Unclosed XMLStreamReader/Writer causes leaking
Ivan created CXF-4523: - Summary: Unclosed XMLStreamReader/Writer causes leaking Key: CXF-4523 URL: https://issues.apache.org/jira/browse/CXF-4523 Project: CXF Issue Type: Bug Affects Versions: 2.6.2 Reporter: Ivan I created some wrapper classes for those XMLStreamReader created in StaxUtils, and found that the one created with the stack below will not invoke the close() method, which will cause some leaking ava.lang.Throwable at org.apache.cxf.staxutils.XXMLStreamReader.(XXMLStreamReader.java:29) at org.apache.cxf.staxutils.XXMLInputFactory.createXMLStreamReader(XXMLInputFactory.java:136) at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1280) at org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:111) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) .. java.lang.Throwable at org.apache.cxf.staxutils.XXMLStreamReader.(XXMLStreamReader.java:29) at org.apache.cxf.staxutils.XXMLInputFactory.createXMLStreamReader(XXMLInputFactory.java:169) at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1363) at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1247) at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:231) at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:191) .. http://cxf.547215.n5.nabble.com/XMLStreamReader-is-never-closed-td5714822.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4523) Unclosed XMLStreamReader/Writer causes leaking
[ https://issues.apache.org/jira/browse/CXF-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan updated CXF-4523: -- Attachment: CXF-4523.patch Create a patch file based on Daniel's suggestion, two interceptors are created for close the created reader. I am not quite sure about the PHASE, now I use the POST_INVOKE. > Unclosed XMLStreamReader/Writer causes leaking > -- > > Key: CXF-4523 > URL: https://issues.apache.org/jira/browse/CXF-4523 > Project: CXF > Issue Type: Bug >Affects Versions: 2.6.2 >Reporter: Ivan > Attachments: CXF-4523.patch > > > I created some wrapper classes for those XMLStreamReader created in > StaxUtils, and found that the one created with the stack below will not > invoke the close() method, which will cause some leaking > ava.lang.Throwable > at org.apache.cxf.staxutils.XXMLStreamReader.(XXMLStreamReader.java:29) > at > org.apache.cxf.staxutils.XXMLInputFactory.createXMLStreamReader(XXMLInputFactory.java:136) > at > org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1280) > at > org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:111) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > .. > java.lang.Throwable > at org.apache.cxf.staxutils.XXMLStreamReader.(XXMLStreamReader.java:29) > at > org.apache.cxf.staxutils.XXMLInputFactory.createXMLStreamReader(XXMLInputFactory.java:169) > at > org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1363) > at > org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1247) > at > org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:231) > at > org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:191) > .. > http://cxf.547215.n5.nabble.com/XMLStreamReader-is-never-closed-td5714822.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4523) Unclosed XMLStreamReader/Writer causes leaking
[ https://issues.apache.org/jira/browse/CXF-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-4523. -- Resolution: Fixed Assignee: Daniel Kulp Slightly modified patch applied. Had to hack around some issues in the JAX-RS frontend that will need to be refactored later. > Unclosed XMLStreamReader/Writer causes leaking > -- > > Key: CXF-4523 > URL: https://issues.apache.org/jira/browse/CXF-4523 > Project: CXF > Issue Type: Bug >Affects Versions: 2.6.2 >Reporter: Ivan >Assignee: Daniel Kulp > Fix For: 2.5.6, 2.6.3 > > Attachments: CXF-4523.patch > > > I created some wrapper classes for those XMLStreamReader created in > StaxUtils, and found that the one created with the stack below will not > invoke the close() method, which will cause some leaking > ava.lang.Throwable > at org.apache.cxf.staxutils.XXMLStreamReader.(XXMLStreamReader.java:29) > at > org.apache.cxf.staxutils.XXMLInputFactory.createXMLStreamReader(XXMLInputFactory.java:136) > at > org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1280) > at > org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:111) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > .. > java.lang.Throwable > at org.apache.cxf.staxutils.XXMLStreamReader.(XXMLStreamReader.java:29) > at > org.apache.cxf.staxutils.XXMLInputFactory.createXMLStreamReader(XXMLInputFactory.java:169) > at > org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1363) > at > org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1247) > at > org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:231) > at > org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:191) > .. > http://cxf.547215.n5.nabble.com/XMLStreamReader-is-never-closed-td5714822.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4523) Unclosed XMLStreamReader/Writer causes leaking
[ https://issues.apache.org/jira/browse/CXF-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-4523: - Fix Version/s: 2.6.3 2.5.6 > Unclosed XMLStreamReader/Writer causes leaking > -- > > Key: CXF-4523 > URL: https://issues.apache.org/jira/browse/CXF-4523 > Project: CXF > Issue Type: Bug >Affects Versions: 2.6.2 >Reporter: Ivan > Fix For: 2.5.6, 2.6.3 > > Attachments: CXF-4523.patch > > > I created some wrapper classes for those XMLStreamReader created in > StaxUtils, and found that the one created with the stack below will not > invoke the close() method, which will cause some leaking > ava.lang.Throwable > at org.apache.cxf.staxutils.XXMLStreamReader.(XXMLStreamReader.java:29) > at > org.apache.cxf.staxutils.XXMLInputFactory.createXMLStreamReader(XXMLInputFactory.java:136) > at > org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1280) > at > org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:111) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > .. > java.lang.Throwable > at org.apache.cxf.staxutils.XXMLStreamReader.(XXMLStreamReader.java:29) > at > org.apache.cxf.staxutils.XXMLInputFactory.createXMLStreamReader(XXMLInputFactory.java:169) > at > org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1363) > at > org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1247) > at > org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:231) > at > org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:191) > .. > http://cxf.547215.n5.nabble.com/XMLStreamReader-is-never-closed-td5714822.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4524) Large request causes socket timeout on subsequent requests on WebLogic hosted service
Chris Pimlott created CXF-4524: -- Summary: Large request causes socket timeout on subsequent requests on WebLogic hosted service Key: CXF-4524 URL: https://issues.apache.org/jira/browse/CXF-4524 Project: CXF Issue Type: Bug Affects Versions: 2.6.2 Environment: WebLogic 10.3.0.0 Reporter: Chris Pimlott I discovered an odd bug that appears to be some sort of interaction between CXF, WebLogic and HTTP keepalives. I have a simple service in a webapp hosted in WebLogic 10.3.0.0. I am hitting that service with a client stub generated from WSDL by cxf-codegen-plugin. The steps are as follows: 1. Create a new client service object 2. Make a first call, passing a fairly large (1000) list of strings 3. Make a second call to any method The first call executes properly, but the second call fails with a socket timeout. If the first call has a smaller or empty list of strings, the issue does not occur. If you add a delay of approx. 5 seconds between the two calls, the issue does not occur. Shorter delays don't seem to be sufficient. If you disable HTTP keepalives, either on the client (via System property) or on the server, the issue does not occur. If I make a call with a fairly large -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4524) Large request causes socket timeout on subsequent requests on WebLogic hosted service
[ https://issues.apache.org/jira/browse/CXF-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Pimlott updated CXF-4524: --- Attachment: stacktrace.weblogic.txt stacktrace.client.txt > Large request causes socket timeout on subsequent requests on WebLogic hosted > service > - > > Key: CXF-4524 > URL: https://issues.apache.org/jira/browse/CXF-4524 > Project: CXF > Issue Type: Bug >Affects Versions: 2.6.2 > Environment: WebLogic 10.3.0.0 >Reporter: Chris Pimlott > Attachments: stacktrace.client.txt, stacktrace.weblogic.txt > > > I discovered an odd bug that appears to be some sort of interaction between > CXF, WebLogic and HTTP keepalives. I have a simple service in a webapp > hosted in WebLogic 10.3.0.0. I am hitting that service with a client stub > generated from WSDL by cxf-codegen-plugin. > The steps are as follows: > 1. Create a new client service object > 2. Make a first call, passing a fairly large (1000) list of strings > 3. Make a second call to any method > The first call executes properly, but the second call fails with a socket > timeout. > If the first call has a smaller or empty list of strings, the issue does not > occur. > If you add a delay of approx. 5 seconds between the two calls, the issue does > not occur. Shorter delays don't seem to be sufficient. > If you disable HTTP keepalives, either on the client (via System property) or > on the server, the issue does not occur. > If I make a call with a fairly large -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4524) Large request causes socket timeout on subsequent requests on WebLogic hosted service
[ https://issues.apache.org/jira/browse/CXF-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Pimlott updated CXF-4524: --- Attachment: weblogic-socketTimeoutBug.zip Attached testcase to demonstrate > Large request causes socket timeout on subsequent requests on WebLogic hosted > service > - > > Key: CXF-4524 > URL: https://issues.apache.org/jira/browse/CXF-4524 > Project: CXF > Issue Type: Bug >Affects Versions: 2.6.2 > Environment: WebLogic 10.3.0.0 >Reporter: Chris Pimlott > Attachments: stacktrace.client.txt, stacktrace.weblogic.txt, > weblogic-socketTimeoutBug.zip > > > I discovered an odd bug that appears to be some sort of interaction between > CXF, WebLogic and HTTP keepalives. I have a simple service in a webapp > hosted in WebLogic 10.3.0.0. I am hitting that service with a client stub > generated from WSDL by cxf-codegen-plugin. > The steps are as follows: > 1. Create a new client service object > 2. Make a first call, passing a fairly large (1000) list of strings > 3. Make a second call to any method > The first call executes properly, but the second call fails with a socket > timeout. > If the first call has a smaller or empty list of strings, the issue does not > occur. > If you add a delay of approx. 5 seconds between the two calls, the issue does > not occur. Shorter delays don't seem to be sufficient. > If you disable HTTP keepalives, either on the client (via System property) or > on the server, the issue does not occur. > If I make a call with a fairly large -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4524) Large request causes socket timeout on subsequent requests on WebLogic hosted service
[ https://issues.apache.org/jira/browse/CXF-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464918#comment-13464918 ] Chris Pimlott commented on CXF-4524: I found a post on the mailing list that looks similar to this, but there didn't seem to be any resolution: http://cxf.547215.n5.nabble.com/TimeOut-Exception-td5529403.html > Large request causes socket timeout on subsequent requests on WebLogic hosted > service > - > > Key: CXF-4524 > URL: https://issues.apache.org/jira/browse/CXF-4524 > Project: CXF > Issue Type: Bug >Affects Versions: 2.6.2 > Environment: WebLogic 10.3.0.0 >Reporter: Chris Pimlott > Attachments: stacktrace.client.txt, stacktrace.weblogic.txt, > weblogic-socketTimeoutBug.zip > > > I discovered an odd bug that appears to be some sort of interaction between > CXF, WebLogic and HTTP keepalives. I have a simple service in a webapp > hosted in WebLogic 10.3.0.0. I am hitting that service with a client stub > generated from WSDL by cxf-codegen-plugin. > The steps are as follows: > 1. Create a new client service object > 2. Make a first call, passing a fairly large (1000) list of strings > 3. Make a second call to any method > The first call executes properly, but the second call fails with a socket > timeout. > If the first call has a smaller or empty list of strings, the issue does not > occur. > If you add a delay of approx. 5 seconds between the two calls, the issue does > not occur. Shorter delays don't seem to be sufficient. > If you disable HTTP keepalives, either on the client (via System property) or > on the server, the issue does not occur. > If I make a call with a fairly large -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4524) Large request causes socket timeout on subsequent requests on WebLogic hosted service
[ https://issues.apache.org/jira/browse/CXF-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Pimlott updated CXF-4524: --- Description: I discovered an odd bug that appears to be some sort of interaction between CXF, WebLogic and HTTP keepalives. I have a simple service in a webapp hosted in WebLogic 10.3.0.0. I am hitting that service with a client stub generated from WSDL by cxf-codegen-plugin. The steps are as follows: 1. Create a new client service object 2. Make a first call, passing a fairly large (1000) list of strings 3. Make a second call to any method The first call executes properly, but the second call fails with a socket timeout. If the first call has a smaller or empty list of strings, the issue does not occur. If you add a delay of approx. 5 seconds between the two calls, the issue does not occur. Shorter delays don't seem to be sufficient. If you disable HTTP keepalives, either on the client (via System property) or on the server, the issue does not occur. was: I discovered an odd bug that appears to be some sort of interaction between CXF, WebLogic and HTTP keepalives. I have a simple service in a webapp hosted in WebLogic 10.3.0.0. I am hitting that service with a client stub generated from WSDL by cxf-codegen-plugin. The steps are as follows: 1. Create a new client service object 2. Make a first call, passing a fairly large (1000) list of strings 3. Make a second call to any method The first call executes properly, but the second call fails with a socket timeout. If the first call has a smaller or empty list of strings, the issue does not occur. If you add a delay of approx. 5 seconds between the two calls, the issue does not occur. Shorter delays don't seem to be sufficient. If you disable HTTP keepalives, either on the client (via System property) or on the server, the issue does not occur. If I make a call with a fairly large > Large request causes socket timeout on subsequent requests on WebLogic hosted > service > - > > Key: CXF-4524 > URL: https://issues.apache.org/jira/browse/CXF-4524 > Project: CXF > Issue Type: Bug >Affects Versions: 2.6.2 > Environment: WebLogic 10.3.0.0 >Reporter: Chris Pimlott > Attachments: stacktrace.client.txt, stacktrace.weblogic.txt, > weblogic-socketTimeoutBug.zip > > > I discovered an odd bug that appears to be some sort of interaction between > CXF, WebLogic and HTTP keepalives. I have a simple service in a webapp > hosted in WebLogic 10.3.0.0. I am hitting that service with a client stub > generated from WSDL by cxf-codegen-plugin. > The steps are as follows: > 1. Create a new client service object > 2. Make a first call, passing a fairly large (1000) list of strings > 3. Make a second call to any method > The first call executes properly, but the second call fails with a socket > timeout. > If the first call has a smaller or empty list of strings, the issue does not > occur. > If you add a delay of approx. 5 seconds between the two calls, the issue does > not occur. Shorter delays don't seem to be sufficient. > If you disable HTTP keepalives, either on the client (via System property) or > on the server, the issue does not occur. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FEDIZ-18) Make supported claims configurable in FileClaimsHandler
[
https://issues.apache.org/jira/browse/FEDIZ-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Wulff reassigned FEDIZ-18:
-
Assignee: Oliver Wulff
> Make supported claims configurable in FileClaimsHandler
> ---
>
> Key: FEDIZ-18
> URL: https://issues.apache.org/jira/browse/FEDIZ-18
> Project: CXF-Fediz
> Issue Type: Improvement
> Components: IDP
>Affects Versions: 1.0.0
>Reporter: Oliver Wulff
>Assignee: Oliver Wulff
>Priority: Minor
> Fix For: 1.0.2
>
>
> The supported claims of the FileClaimsHandler are managed in the code:
> public List getSupportedClaimTypes()
> {
> ArrayList list = new ArrayList();
> list.add(ClaimTypes.EMAILADDRESS);
> list.add(ClaimTypes.LASTNAME);
> list.add(ClaimTypes.FIRSTNAME);
> list.add(ROLE);
> return list;
> }
> This should be configurable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FEDIZ-18) Make supported claims configurable in FileClaimsHandler
[
https://issues.apache.org/jira/browse/FEDIZ-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Wulff resolved FEDIZ-18.
---
Resolution: Fixed
Fix Version/s: 1.0.2
> Make supported claims configurable in FileClaimsHandler
> ---
>
> Key: FEDIZ-18
> URL: https://issues.apache.org/jira/browse/FEDIZ-18
> Project: CXF-Fediz
> Issue Type: Improvement
> Components: IDP
>Affects Versions: 1.0.0
>Reporter: Oliver Wulff
>Assignee: Oliver Wulff
>Priority: Minor
> Fix For: 1.0.2
>
>
> The supported claims of the FileClaimsHandler are managed in the code:
> public List getSupportedClaimTypes()
> {
> ArrayList list = new ArrayList();
> list.add(ClaimTypes.EMAILADDRESS);
> list.add(ClaimTypes.LASTNAME);
> list.add(ClaimTypes.FIRSTNAME);
> list.add(ROLE);
> return list;
> }
> This should be configurable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FEDIZ-18) Make supported claims configurable in FileClaimsHandler
[
https://issues.apache.org/jira/browse/FEDIZ-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464927#comment-13464927
]
Oliver Wulff commented on FEDIZ-18:
---
supportedClaims bean added to userClaims.xml which is referenced by
fileClaimsHandler bean.
> Make supported claims configurable in FileClaimsHandler
> ---
>
> Key: FEDIZ-18
> URL: https://issues.apache.org/jira/browse/FEDIZ-18
> Project: CXF-Fediz
> Issue Type: Improvement
> Components: IDP
>Affects Versions: 1.0.0
>Reporter: Oliver Wulff
>Assignee: Oliver Wulff
>Priority: Minor
> Fix For: 1.0.2
>
>
> The supported claims of the FileClaimsHandler are managed in the code:
> public List getSupportedClaimTypes()
> {
> ArrayList list = new ArrayList();
> list.add(ClaimTypes.EMAILADDRESS);
> list.add(ClaimTypes.LASTNAME);
> list.add(ClaimTypes.FIRSTNAME);
> list.add(ROLE);
> return list;
> }
> This should be configurable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Need some help with WADL2Java Tool
Hi Guys,
I went through the documentation, which helped me figure out several issues
I had, but not the following two problems:
1) I have got a get(GET) method: get(@Context Request request,
@PathParam("isbn")String isbn)
How do I formulate the WADL for it so that I get the @Context in the
produced Java code?
2) I have got a update (PUT) method: update(@PathParam("isbn") String isbn,
BookState st)
How do I formuate the WADL to get the BookState in the produced Java code?
Here is my current WADL, which does not do it:
Thank u so much,
Behzad
--
View this message in context:
http://cxf.547215.n5.nabble.com/Need-some-help-with-WADL2Java-Tool-tp5714978.html
Sent from the cxf-issues mailing list archive at Nabble.com.
[jira] [Assigned] (FEDIZ-17) Current Fediz STS exposes SOAP 1.1 end point
[ https://issues.apache.org/jira/browse/FEDIZ-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Wulff reassigned FEDIZ-17: - Assignee: Oliver Wulff > Current Fediz STS exposes SOAP 1.1 end point > > > Key: FEDIZ-17 > URL: https://issues.apache.org/jira/browse/FEDIZ-17 > Project: CXF-Fediz > Issue Type: Improvement > Components: IDP >Affects Versions: 1.0.0 > Environment: With SOAP 1.1 end points, if send 1.2 format request, we > are receiving following error message. With current release, users have to > manually convert endpoints to 1.2 format to send 1.2 request. > If Fediz STS end points implemented in 1.2 format, it could take both 1.1 and > 1.2 request. > << > A SOAP 1.2 message is not valid when sent to a SOAP 1.1 only endpoint. > >> >Reporter: Gina Choi >Assignee: Oliver Wulff > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-291) Support Commons HTTP Client for HTTP conduit
[ https://issues.apache.org/jira/browse/CXF-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464953#comment-13464953 ] Shaun Elliott commented on CXF-291: --- I too would like to see this happen. CXF doesn't work well with NTLM, but the Commons HTTP client does. This is just one of many possible use cases for allowing developers to swap out the underlying client. > Support Commons HTTP Client for HTTP conduit > > > Key: CXF-291 > URL: https://issues.apache.org/jira/browse/CXF-291 > Project: CXF > Issue Type: New Feature > Components: Transports >Affects Versions: 2.0 >Reporter: Dan Diephouse > Labels: gsoc2011 > > I think commons http client is a must in terms of HTTP support as it supports > a lot of different authentication modes that I don't know that we currently > support. It shouldn't be that hard to integrate either. XFire users tend to > depend pretty heavily on it. The XFire code can be found here: > http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-core/src/main/org/codehaus/xfire/transport/http/CommonsHttpMessageSender.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FEDIZ-17) Current Fediz STS exposes SOAP 1.1 end point
[ https://issues.apache.org/jira/browse/FEDIZ-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464954#comment-13464954 ] Oliver Wulff commented on FEDIZ-17: --- I committed a fix here: http://svn.apache.org/viewvc?view=revision&revision=1391157 > Current Fediz STS exposes SOAP 1.1 end point > > > Key: FEDIZ-17 > URL: https://issues.apache.org/jira/browse/FEDIZ-17 > Project: CXF-Fediz > Issue Type: Improvement > Components: IDP >Affects Versions: 1.0.0 > Environment: With SOAP 1.1 end points, if send 1.2 format request, we > are receiving following error message. With current release, users have to > manually convert endpoints to 1.2 format to send 1.2 request. > If Fediz STS end points implemented in 1.2 format, it could take both 1.1 and > 1.2 request. > << > A SOAP 1.2 message is not valid when sent to a SOAP 1.1 only endpoint. > >> >Reporter: Gina Choi >Assignee: Oliver Wulff > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-291) Support Commons HTTP Client for HTTP conduit
[ https://issues.apache.org/jira/browse/CXF-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464976#comment-13464976 ] Daniel Kulp commented on CXF-291: - The CXF trunk code (targeting 2.7.0) now has an optional AsyncClient based transport. Some information at: http://cxf.apache.org/docs/asynchronous-client-http-transport.html > Support Commons HTTP Client for HTTP conduit > > > Key: CXF-291 > URL: https://issues.apache.org/jira/browse/CXF-291 > Project: CXF > Issue Type: New Feature > Components: Transports >Affects Versions: 2.0 >Reporter: Dan Diephouse > Labels: gsoc2011 > > I think commons http client is a must in terms of HTTP support as it supports > a lot of different authentication modes that I don't know that we currently > support. It shouldn't be that hard to integrate either. XFire users tend to > depend pretty heavily on it. The XFire code can be found here: > http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-core/src/main/org/codehaus/xfire/transport/http/CommonsHttpMessageSender.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-291) Support Commons HTTP Client for HTTP conduit
[ https://issues.apache.org/jira/browse/CXF-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-291. - Resolution: Fixed Fix Version/s: 2.7.0 Assignee: Daniel Kulp Marking this resolved for 2.7.0 as all the CXF tests pass when using it instead of the older HTTPUrlConnection based transport. Thus, it's considered feature complete. Any "issues" with it would now be considered bugs. > Support Commons HTTP Client for HTTP conduit > > > Key: CXF-291 > URL: https://issues.apache.org/jira/browse/CXF-291 > Project: CXF > Issue Type: New Feature > Components: Transports >Affects Versions: 2.0 >Reporter: Dan Diephouse >Assignee: Daniel Kulp > Labels: gsoc2011 > Fix For: 2.7.0 > > > I think commons http client is a must in terms of HTTP support as it supports > a lot of different authentication modes that I don't know that we currently > support. It shouldn't be that hard to integrate either. XFire users tend to > depend pretty heavily on it. The XFire code can be found here: > http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-core/src/main/org/codehaus/xfire/transport/http/CommonsHttpMessageSender.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4397) Cached Reader/Writer in org.apache.cxf.io
[ https://issues.apache.org/jira/browse/CXF-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-4397. -- Resolution: Fixed Fix Version/s: 2.7.0 Assignee: Daniel Kulp > Cached Reader/Writer in org.apache.cxf.io > - > > Key: CXF-4397 > URL: https://issues.apache.org/jira/browse/CXF-4397 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 2.6.1 >Reporter: Dr. Dietmar Wolz >Assignee: Daniel Kulp > Fix For: 2.7.0 > > > In version 2.6 support of Readers/Writers attached to the message > representing the content were added. Implementation of SAM for Talend ESB > needed to be adapted in case JMS is used as transport. The current fix > converts attached Readers/Writers to streams in SAM using UTF-8 encoding. It > works but I am not sure this is consistent with what was indended by > supporting Readers/Writers in CXF. To defer encoding also in case monitoring > is enabled I would prefer to use cached Readers/Writers instead converting > into streams thereby fixing the encoding. Proper place for cached > Reader/Writer would be org.apache.cxf.io, where the already existing cached > streams are located. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4525) expose http client
Shaun Elliott created CXF-4525: -- Summary: expose http client Key: CXF-4525 URL: https://issues.apache.org/jira/browse/CXF-4525 Project: CXF Issue Type: Improvement Components: Transports Affects Versions: 2.7.0 Reporter: Shaun Elliott Fix For: 2.7.0 The class: CXFAsyncRequester hides the DefaultHttpAsyncClient, thus preventing interaction from outside classes. One use case would be to leverage the embedded DefaultHttpAsyncClient to do NTLM authentication, which is currently not possible with CXF. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-291) Support Commons HTTP Client for HTTP conduit
[ https://issues.apache.org/jira/browse/CXF-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13465142#comment-13465142 ] Shaun Elliott commented on CXF-291: --- Ok, great thanks. I have filed a new improvement task to get at the underlying client. As is, it still does not solve my use case (NTLM authentication). > Support Commons HTTP Client for HTTP conduit > > > Key: CXF-291 > URL: https://issues.apache.org/jira/browse/CXF-291 > Project: CXF > Issue Type: New Feature > Components: Transports >Affects Versions: 2.0 >Reporter: Dan Diephouse >Assignee: Daniel Kulp > Labels: gsoc2011 > Fix For: 2.7.0 > > > I think commons http client is a must in terms of HTTP support as it supports > a lot of different authentication modes that I don't know that we currently > support. It shouldn't be that hard to integrate either. XFire users tend to > depend pretty heavily on it. The XFire code can be found here: > http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-core/src/main/org/codehaus/xfire/transport/http/CommonsHttpMessageSender.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4525) expose http client
[ https://issues.apache.org/jira/browse/CXF-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shaun Elliott updated CXF-4525: --- Description: The class: CXFAsyncRequester hides the DefaultHttpAsyncClient, thus preventing interaction from outside classes. One use case would be to leverage the embedded DefaultHttpAsyncClient to do NTLM authentication, which is currently not possible with CXF. AsyncHTTPConduit will also need a getter on the factory field. was:The class: CXFAsyncRequester hides the DefaultHttpAsyncClient, thus preventing interaction from outside classes. One use case would be to leverage the embedded DefaultHttpAsyncClient to do NTLM authentication, which is currently not possible with CXF. > expose http client > -- > > Key: CXF-4525 > URL: https://issues.apache.org/jira/browse/CXF-4525 > Project: CXF > Issue Type: Improvement > Components: Transports >Affects Versions: 2.7.0 >Reporter: Shaun Elliott > Fix For: 2.7.0 > > > The class: CXFAsyncRequester hides the DefaultHttpAsyncClient, thus > preventing interaction from outside classes. One use case would be to > leverage the embedded DefaultHttpAsyncClient to do NTLM authentication, which > is currently not possible with CXF. > AsyncHTTPConduit will also need a getter on the factory field. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
