[
https://issues.apache.org/jira/browse/CXF-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16853393#comment-16853393
]
Ranjit Vadakkan edited comment on CXF-7898 at 5/31/19 8:16 PM:
---------------------------------------------------------------
Can you post your WSDL please? I ran into this problem when creating a test
client from [http://www.xignite.com/xCurrencies.asmx?wsdl], but this WSDL
defines 4 bindings -
# XigniteCurrenciesSoap
# XigniteCurrenciesSoap12
# XigniteCurrenciesHttpGet
# XigniteCurrenciesHttpPost
Only the first 2 are SOAP, and only the SOAP bindings have valid Operations >
MessageParts > TypeClass. As far as I can see, this is by design because
org.apache.cxf.endpoint.ClientImpl#findEndpoint
([https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/endpoint/ClientImpl.java])
filters out non-SOAP bindings. And only valid SOAP binding 'ServiceInfos' are
populated with valid TypeClass info, see
org.apache.cxf.endpoint.dynamic.DynamicClientFactory#createClient(URL, QName,
ClassLoader, QName, List<String>)
([https://github.com/apache/cxf/blob/master/rt/frontend/simple/src/main/java/org/apache/cxf/endpoint/dynamic/DynamicClientFactory.java])
... at the very bottom where TypeClassInitializer sets the TypeClass on
ServiceInfos from ClientImpl.
You should filter your bindings just like ClientImpl does. For example:
{quote}for (ServiceInfo service: services) {
Collection<BindingInfo> bindings = service.getBindings().stream()
.filter(bi ->
"http://schemas.xmlsoap.org/wsdl/soap/".equals(bi.getBindingId()) ||
"http://schemas.xmlsoap.org/wsdl/soap12/".equals(bi.getBindingId()))
.collect(Collectors.toList());
// iterate over bindings
for (BindingInfo binding: bindings) {
...
{quote}
was (Author: rvadakkan):
Can you post your WSDL please? I ran into this problem when creating a test
client from [http://www.xignite.com/xCurrencies.asmx?wsdl], but this WSDL
defines 4 bindings -
# XigniteCurrenciesSoap
# XigniteCurrenciesSoap12
# XigniteCurrenciesHttpGet
# XigniteCurrenciesHttpPost
Only the first 2 are SOAP, and only the SOAP bindings have valid Operations >
MessageParts > TypeClass. As far as I can see, this is by design because
org.apache.cxf.endpoint.ClientImpl#findEndpoint
([https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/endpoint/ClientImpl.java])
filters out non-SOAP bindings. And only those SOAP binding 'ServiceInfos' are
populated with valid TypeClass info, see
org.apache.cxf.endpoint.dynamic.DynamicClientFactory#createClient(URL, QName,
ClassLoader, QName, List<String>)
([https://github.com/apache/cxf/blob/master/rt/frontend/simple/src/main/java/org/apache/cxf/endpoint/dynamic/DynamicClientFactory.java])
... at the very bottom where TypeClassInitializer sets the TypeClass on
ServiceInfos from ClientImpl.
You should filter your bindings just like ClientImpl does. For example:
{quote}for (ServiceInfo service: services) {
Collection<BindingInfo> bindings = service.getBindings().stream()
.filter(bi ->
"http://schemas.xmlsoap.org/wsdl/soap/".equals(bi.getBindingId()) ||
"http://schemas.xmlsoap.org/wsdl/soap12/".equals(bi.getBindingId()))
.collect(Collectors.toList());
// iterate over bindings
for (BindingInfo binding: bindings) {
...
{quote}
> Cxf returns 'null' on MessagePartInfo typeClass in services with multiple
> portTypes
> -----------------------------------------------------------------------------------
>
> Key: CXF-7898
> URL: https://issues.apache.org/jira/browse/CXF-7898
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
> Reporter: Mathaus Erich Ramos
> Priority: Major
>
> Recently I started using the Apache Cxf lib with the intention of performing
> the extraction of operation attributes in a WSDL files for SOAP Web Services.
> That's because before the company where I worked had many problems with the
> old lib, the Predic8.
> However, recently I tried to extract the attributes of a WSDL operation and I
> was not able to get the expected result. From what I have analyzed with some
> tests, it is not able to identify the type of the Class of the attributes
> that have more than one binding. However with some tests I performed,
> changing the portType of all bindings to the same I was able to get it to
> interpret correctly.
> I believe the problem is occurring when there is more and a binding and each
> uses a different PortType, since it can only extract the type of classes from
> the attributes in one of the portTypes.
> Please give me a light.
> *Code used to extract:*
> {code:java}
> public class DynClient {
>
>
> public static void main(String[] args) {
> JaxWsDynamicClientFactory factory =
> JaxWsDynamicClientFactory.newInstance();
> Client client =
> factory.createClient("http://intsaprm.hptransportes.com.br:8051/wsConsultaSQL/MEX?wsdl";);
>
> for (ServiceInfo service :
> client.getEndpoint().getService().getServiceInfos()) {
> for (BindingInfo binding : service.getBindings()) {
> System.out.println("Binding: " +
> binding.getName().getLocalPart());
> binding.getOperations().forEach(operation -> {
>
> if (operation.getInput() != null) {
>
> operation.getInput().getMessageParts().forEach(part
> -> {
> System.out.println(part.getName().getLocalPart()
> + "=>" + part.getTypeClass());
> });
> }
> if (operation.getOutput() != null) {
> operation.getOutput().getMessageParts().forEach(part
> -> {
> System.out.println(part.getName().getLocalPart()
> + "=>" + part.getTypeClass());
> });
> }
> });
> }
> }
>
> }
> }{code}
>
> *When executed:*
> {panel:title=Output}
> Binding: RM_IwsBase
> parameters=>class com.totvs.CheckServiceActivity
> parameters=>class com.totvs.CheckServiceActivityResponse
> parameters=>class com.totvs.AutenticaAcesso
> parameters=>class com.totvs.AutenticaAcessoResponse
> parameters=>class com.totvs.Implements
> parameters=>class com.totvs.ImplementsResponse
> Binding: RM_IwsConsultaSQL
> parameters=>null
> parameters=>null
> parameters=>null
> parameters=>null
> parameters=>null
> parameters=>null
> Binding: RM_IRMSServer
> parameters=>null
> parameters=>null
> parameters=>null
> parameters=>null
> {panel}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
