[jira] [Created] (CXF-4248) DocLiteralInInterceptor throws NPE if oneWay operation sends non-empty response
DocLiteralInInterceptor throws NPE if oneWay operation sends non-empty response --- Key: CXF-4248 URL: https://issues.apache.org/jira/browse/CXF-4248 Project: CXF Issue Type: Improvement Reporter: Andrei Shakirin Priority: Minor Attachments: HTTPConduit.patch Hi, Test case: Web service provides oneWay operation (SoapUI mock), but sends non-empty SOAP response back Expected: response will be ignored Actual: DocLiteralInInterceptor throws NPE Caused by: java.lang.NullPointerException at org.apache.cxf.interceptor.DocLiteralInInterceptor.shouldWrapParameters(DocLiteralInInterceptor.java:292) at org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:103) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1627) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1494) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1402) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:649) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSende rInterceptor.java:62) Fix proposal: I have discovered that there are some cases when oneWay response can be proceeded. Regarding Basic Profile 1.1: R2714 For one-way operations, an HTTP Response MESSAGE MAY contain an envelope. One-way operations typically do not produce SOAP responses. However, some INSTANCEs may choose to communicate infrastructure-related faults (e.g. MustUnderstand, VersionMismatch) in the HTTP Response message. In addition to this, the use of some protocol extensions (e.g. WS-ReliableMessaging) may create the possibility for non-empty responses to one-way messages. For these reasons the Basic Profile 1.1 requirement that the HTTP Response message not contain a SOAP envelope has been relaxed. I would propose to process oneWay response only in following cases: A) if RM is active (check RMMessageConstants.RM_PROPERTIES_OUTBOUND, RMMessageConstants.RM_PROPERTIES_INBOUND) B) if user activate it with org.apache.cxf.transport.processOneWayResponse property on consumer In other case oneWay response will be ignored by client. Patch is attached. Regards, Andrei. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4248) DocLiteralInInterceptor throws NPE if oneWay operation sends non-empty response
[ https://issues.apache.org/jira/browse/CXF-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin updated CXF-4248: - Attachment: HTTPConduit.patch > DocLiteralInInterceptor throws NPE if oneWay operation sends non-empty > response > --- > > Key: CXF-4248 > URL: https://issues.apache.org/jira/browse/CXF-4248 > Project: CXF > Issue Type: Improvement >Reporter: Andrei Shakirin >Priority: Minor > Attachments: HTTPConduit.patch > > > Hi, > Test case: Web service provides oneWay operation (SoapUI mock), but sends > non-empty SOAP response back > Expected: response will be ignored > Actual: DocLiteralInInterceptor throws NPE > Caused by: java.lang.NullPointerException > at > org.apache.cxf.interceptor.DocLiteralInInterceptor.shouldWrapParameters(DocLiteralInInterceptor.java:292) > at > org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:103) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) > at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1627) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1494) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1402) > at > org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at > org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:649) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSende > rInterceptor.java:62) > Fix proposal: I have discovered that there are some cases when oneWay > response can be proceeded. Regarding Basic Profile 1.1: > R2714 For one-way operations, an HTTP Response MESSAGE MAY contain an > envelope. > One-way operations typically do not produce SOAP responses. However, some > INSTANCEs may choose to communicate infrastructure-related faults (e.g. > MustUnderstand, VersionMismatch) in the HTTP Response message. > In addition to this, the use of some protocol extensions (e.g. > WS-ReliableMessaging) may create the possibility for non-empty responses to > one-way messages. For these reasons the Basic Profile 1.1 requirement that > the HTTP Response message not contain a SOAP envelope has been relaxed. > I would propose to process oneWay response only in following cases: > A) if RM is active (check RMMessageConstants.RM_PROPERTIES_OUTBOUND, > RMMessageConstants.RM_PROPERTIES_INBOUND) > B) if user activate it with org.apache.cxf.transport.processOneWayResponse > property on consumer > In other case oneWay response will be ignored by client. > Patch is attached. > Regards, > Andrei. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4248) DocLiteralInInterceptor throws NPE if oneWay operation sends non-empty response
[ https://issues.apache.org/jira/browse/CXF-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin updated CXF-4248: - Description: Hi, Test case: Web service provides oneWay operation (SoapUI mock), but sends non-empty SOAP response back Expected: response will be ignored Actual: DocLiteralInInterceptor throws NPE Caused by: java.lang.NullPointerException at org.apache.cxf.interceptor.DocLiteralInInterceptor.shouldWrapParameters(DocLiteralInInterceptor.java:292) at org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:103) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1627) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1494) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1402) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:649) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSende rInterceptor.java:62) Fix proposal: I have discovered that there are some cases when oneWay response can be proceeded. Regarding Basic Profile 1.1: R2714 For one-way operations, an HTTP Response MESSAGE MAY contain an envelope. One-way operations typically do not produce SOAP responses. However, some INSTANCEs may choose to communicate infrastructure-related faults (e.g. MustUnderstand, VersionMismatch) in the HTTP Response message. In addition to this, the use of some protocol extensions (e.g. WS-ReliableMessaging) may create the possibility for non-empty responses to one-way messages. For these reasons the Basic Profile 1.1 requirement that the HTTP Response message not contain a SOAP envelope has been relaxed. I would propose to process successful oneWay responses only in following cases: A) if RM is active (check RMMessageConstants.RM_PROPERTIES_OUTBOUND, RMMessageConstants.RM_PROPERTIES_INBOUND) B) if user activate it with org.apache.cxf.transport.processOneWayResponse property on consumer In other case oneWay response will be ignored by client. Patch is attached. Regards, Andrei. was: Hi, Test case: Web service provides oneWay operation (SoapUI mock), but sends non-empty SOAP response back Expected: response will be ignored Actual: DocLiteralInInterceptor throws NPE Caused by: java.lang.NullPointerException at org.apache.cxf.interceptor.DocLiteralInInterceptor.shouldWrapParameters(DocLiteralInInterceptor.java:292) at org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:103) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1627) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1494) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1402) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:649) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSende rInterceptor.java:62) Fix proposal: I have discovered that there are some cases when oneWay response can be proceeded. Regarding Basic Profile 1.1: R2714 For one-way operations, an HTTP Response MESSAGE MAY contain an envelope. One-way operations typically do not produce SOAP responses. However, some INSTANCEs may choose to communicate infrastructure-related faults (e.g. MustUnderstand, VersionMismatch) in the HTTP Response message. In addition to this, the use of some protocol extensions (e.g. WS-ReliableMessaging) may create the possibility for non-empty responses to one-way messages. For these reasons the Basic Profile 1.1 requirement that the HTTP Response message not contain a SOAP envelope has been relaxed. I would propose to process oneWay response only in following cases: A) if RM is active (check RMMessageConstants.RM_PROPERTIES_OUTBOUND, RMMessageConstants.RM_PROPERTIES_INBOUND) B) if user activate it with org.apache.cxf.transport.processOneWayResponse property on consumer In other case oneWay response will be ignored by client. Patch is attached. Regards, Andrei. > DocLiteralInInterceptor throws NPE if
[jira] [Updated] (CXF-4248) DocLiteralInInterceptor throws NPE if oneWay operation sends non-empty response
[ https://issues.apache.org/jira/browse/CXF-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin updated CXF-4248: - Description: Hi, Test case: Web service provides oneWay operation (SoapUI mock), but sends non-empty SOAP response back Expected: response will be ignored Actual: DocLiteralInInterceptor throws NPE Caused by: java.lang.NullPointerException at org.apache.cxf.interceptor.DocLiteralInInterceptor.shouldWrapParameters(DocLiteralInInterceptor.java:292) at org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:103) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1627) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1494) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1402) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:649) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSende rInterceptor.java:62) Fix proposal: I have discovered that there are some cases when oneWay response can be proceeded. Regarding Basic Profile 1.1: R2714 For one-way operations, an HTTP Response MESSAGE MAY contain an envelope. One-way operations typically do not produce SOAP responses. However, some INSTANCEs may choose to communicate infrastructure-related faults (e.g. MustUnderstand, VersionMismatch) in the HTTP Response message. In addition to this, the use of some protocol extensions (e.g. WS-ReliableMessaging) may create the possibility for non-empty responses to one-way messages. For these reasons the Basic Profile 1.1 requirement that the HTTP Response message not contain a SOAP envelope has been relaxed. I would propose to process successful oneWay responses only in following cases: A) if RM is active (check RMMessageConstants.RM_PROPERTIES_OUTBOUND, RMMessageConstants.RM_PROPERTIES_INBOUND) B) if user activate it with org.apache.cxf.transport.processOneWayResponse property on client. In other case oneWay response will be ignored by client. Patch is attached. Regards, Andrei. was: Hi, Test case: Web service provides oneWay operation (SoapUI mock), but sends non-empty SOAP response back Expected: response will be ignored Actual: DocLiteralInInterceptor throws NPE Caused by: java.lang.NullPointerException at org.apache.cxf.interceptor.DocLiteralInInterceptor.shouldWrapParameters(DocLiteralInInterceptor.java:292) at org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:103) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1627) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1494) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1402) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:649) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSende rInterceptor.java:62) Fix proposal: I have discovered that there are some cases when oneWay response can be proceeded. Regarding Basic Profile 1.1: R2714 For one-way operations, an HTTP Response MESSAGE MAY contain an envelope. One-way operations typically do not produce SOAP responses. However, some INSTANCEs may choose to communicate infrastructure-related faults (e.g. MustUnderstand, VersionMismatch) in the HTTP Response message. In addition to this, the use of some protocol extensions (e.g. WS-ReliableMessaging) may create the possibility for non-empty responses to one-way messages. For these reasons the Basic Profile 1.1 requirement that the HTTP Response message not contain a SOAP envelope has been relaxed. I would propose to process successful oneWay responses only in following cases: A) if RM is active (check RMMessageConstants.RM_PROPERTIES_OUTBOUND, RMMessageConstants.RM_PROPERTIES_INBOUND) B) if user activate it with org.apache.cxf.transport.processOneWayResponse property on consumer In other case oneWay response will be ignored by client. Patch is attached. Regards, Andrei. > DocLiteralInInterceptor thr
[jira] [Updated] (CXF-4248) DocLiteralInInterceptor throws NPE if oneWay operation sends non-empty response
[ https://issues.apache.org/jira/browse/CXF-4248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin updated CXF-4248: - Description: Hi, Test case: Web service provides oneWay operation (SoapUI mock), but sends non-empty SOAP response back Expected: response will be ignored Actual: DocLiteralInInterceptor throws NPE Caused by: java.lang.NullPointerException at org.apache.cxf.interceptor.DocLiteralInInterceptor.shouldWrapParameters(DocLiteralInInterceptor.java:292) at org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:103) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1627) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1494) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1402) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:649) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSende rInterceptor.java:62) Fix proposal: I have discovered (thanks Aki!) that there are some cases when oneWay response can be proceeded. Regarding Basic Profile 1.1: R2714 For one-way operations, an HTTP Response MESSAGE MAY contain an envelope. One-way operations typically do not produce SOAP responses. However, some INSTANCEs may choose to communicate infrastructure-related faults (e.g. MustUnderstand, VersionMismatch) in the HTTP Response message. In addition to this, the use of some protocol extensions (e.g. WS-ReliableMessaging) may create the possibility for non-empty responses to one-way messages. For these reasons the Basic Profile 1.1 requirement that the HTTP Response message not contain a SOAP envelope has been relaxed. I would propose to process successful oneWay responses only in following cases: A) if RM is active (check RMMessageConstants.RM_PROPERTIES_OUTBOUND, RMMessageConstants.RM_PROPERTIES_INBOUND) B) if user activate it with org.apache.cxf.transport.processOneWayResponse property on client. In other case oneWay response will be ignored by client. Patch is attached. Regards, Andrei. was: Hi, Test case: Web service provides oneWay operation (SoapUI mock), but sends non-empty SOAP response back Expected: response will be ignored Actual: DocLiteralInInterceptor throws NPE Caused by: java.lang.NullPointerException at org.apache.cxf.interceptor.DocLiteralInInterceptor.shouldWrapParameters(DocLiteralInInterceptor.java:292) at org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:103) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1627) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1494) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1402) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:649) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSende rInterceptor.java:62) Fix proposal: I have discovered that there are some cases when oneWay response can be proceeded. Regarding Basic Profile 1.1: R2714 For one-way operations, an HTTP Response MESSAGE MAY contain an envelope. One-way operations typically do not produce SOAP responses. However, some INSTANCEs may choose to communicate infrastructure-related faults (e.g. MustUnderstand, VersionMismatch) in the HTTP Response message. In addition to this, the use of some protocol extensions (e.g. WS-ReliableMessaging) may create the possibility for non-empty responses to one-way messages. For these reasons the Basic Profile 1.1 requirement that the HTTP Response message not contain a SOAP envelope has been relaxed. I would propose to process successful oneWay responses only in following cases: A) if RM is active (check RMMessageConstants.RM_PROPERTIES_OUTBOUND, RMMessageConstants.RM_PROPERTIES_INBOUND) B) if user activate it with org.apache.cxf.transport.processOneWayResponse property on client. In other case oneWay response will be ignored by client. Patch is attached. Regards, Andrei. > DocLiteralInIn
[jira] [Created] (CXF-4249) Make RMTxStore's current schema name to be configurable
Make RMTxStore's current schema name to be configurable --- Key: CXF-4249 URL: https://issues.apache.org/jira/browse/CXF-4249 Project: CXF Issue Type: Improvement Components: WS-* Components Reporter: Aki Yoshida Assignee: Aki Yoshida Priority: Minor Fix For: 2.6.1 Make the current schema name of RMTxStore to be configurable per RMTxStore instance so that one can use the same database to host multiple overlapping scenarios or in other words, to host groups of scenarios in isolation (e.g., for multiple tenants). Basically, the idea is to add property schenaName. When it is set, it is used to set the current schema to this specific schema. If unset, it uses the default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-2451) Unable to call no-arg methods when using implicit headers - getting params [null]
[ https://issues.apache.org/jira/browse/CXF-2451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257782#comment-13257782 ] Mario Nocnik commented on CXF-2451: --- Could you please solve this Issue for 2.5.2 or at least 2.6.0 also please. Or is there a known workaround which allows custom login modules with interceptors and custom soap secutity header? > Unable to call no-arg methods when using implicit headers - getting params > [null] > - > > Key: CXF-2451 > URL: https://issues.apache.org/jira/browse/CXF-2451 > Project: CXF > Issue Type: Bug >Affects Versions: 2.2.3 > Environment: ALL >Reporter: Arik Gorelik >Assignee: Daniel Kulp > Fix For: 2.1.7, 2.2.4 > > > Hello, > I am a developer using CXF 2.2.3. I am currently running into an issue when > trying to call a NO-ARG method getFoo() > while using implicit headers defined ONLY at the wsdl:binding section. > Each header has a SEPARATE wsdl:message defined and headers elements are NOT > part of the getFooRequest wsdl:message. > The generated code looks correct (using wsdl2java); however, invoking the > method results in the error message in the following soap fault message: > wrong number of arguments while invoking public > com.test.services.v29.FooResponse > com.test.services.v29.TestServiceImpl.getFoo() throws > com.test.services.v29.TestException with params [null]. > Here is the stack trace: > WARNING: Application has thrown exception, unwinding now > org.apache.cxf.interceptor.Fault: wrong number of arguments while invoking > public com.test.services.v29.FooResponse > com.test.services.v29.TestServiceImpl.getFoo() throws > com.test.services.v29.TestException with params [null]. > at > org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:152) > at > org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:83) > at > org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:126) > at > org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:55) > at > org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:68) > at > org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at > org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:98) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:104) > at > org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:99) > at > org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:452) > at > org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:196) > at > org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:220) > at > org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:153) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) > > Caused by: java.lang.IllegalArgumentException: wrong number of arguments > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:166) > at > org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:82) > ... 33 more > Request is: > http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:v29="http://test.com/services/v29";> > > 1234 > abcd > > > > > > Generated code is: > @WebResult(name = "response", targetNamespace = > "http://test/services/v29";) > @RequestWrapper(localName = "getFoo", targetNamespace = > "http://test.com/services/v29";, className = "com.test.services.v29.GetFoo") > @ResponseWrapper(localName = "getFooResponse", targetNamespace = > "http://test.com/services/v29";, className = > "com.test.services.v29.GetFooResponse
[jira] [Created] (CXF-4250) WADL To Java Generator fails to process application level method elements
WADL To Java Generator fails to process application level method elements -- Key: CXF-4250 URL: https://issues.apache.org/jira/browse/CXF-4250 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 2.6, 2.5.3 Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Fix For: 2.6.1, 2.5.4 The generator throws a ClassCastException if a WADL method is declared as a child of the wadl:application element -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4250) WADL To Java Generator fails to process application level method elements
[ https://issues.apache.org/jira/browse/CXF-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-4250. --- Resolution: Fixed > WADL To Java Generator fails to process application level method elements > -- > > Key: CXF-4250 > URL: https://issues.apache.org/jira/browse/CXF-4250 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 2.5.3, 2.6 >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 2.6.1, 2.5.4 > > > The generator throws a ClassCastException if a WADL method is declared as a > child of the wadl:application element -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4251) Error when calling methods with the similar parameters
Error when calling methods with the similar parameters -- Key: CXF-4251 URL: https://issues.apache.org/jira/browse/CXF-4251 Project: CXF Issue Type: Bug Components: JAX-WS Runtime Affects Versions: 2.6 Environment: Tomcat 6.0.26 Reporter: Jury Litvinoff Priority: Critical Two methods with similar parameters - Example code: @WebMethod(operationName="saveCosts", action="costs") public String saveCosts(@WebParam(name = "way")String way, @WebParam(name = "item")String item, @WebParam(name = "project")String proj, @WebParam(name = "period")String period, @WebParam(name = "val")String val); @WebMethod(operationName="saveBalance", action="balance") public String saveBalance(@WebParam(name = "way")String way, @WebParam(name = "item")String item, @WebParam(name = "project")String proj, @WebParam(name = "period")String period, @WebParam(name = "val")String val); When you call "saveCosts", Web service transfers control to another method - "saveBalance"!!! Why??? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
