When I deploy a JAX-WS as a standard web application service through Glassfish everything works fine.
The same JAR file is also an OSGi bundle (so a WAB). If I try to install as an OSGi bundle, I get an error about the return property not being there for the response. This is the web service class:
package org.example;
import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.xml.ws.ResponseWrapper;
#WebService
public class ExampleComponent {
private String message = new String("Hello, ");
public ExampleComponent() {
}
public String sayHello(String name) {
return message + name + ".";
}
}
This is the error I get:
javax.xml.ws.WebServiceException: class org.example.Wrapper do not have a property of the name return
at com.sun.xml.ws.server.sei.EndpointResponseMessageBuilder$DocLit.<init>(EndpointResponseMessageBuilder.java:217)
at com.sun.xml.ws.server.sei.TieHandler.createResponseMessageBuilder(TieHandler.java:210)
at com.sun.xml.ws.server.sei.TieHandler.<init>(TieHandler.java:116)
at com.sun.xml.ws.db.DatabindingImpl.<init>(DatabindingImpl.java:108)
at com.sun.xml.ws.db.DatabindingProviderImpl.create(DatabindingProviderImpl.java:74)
at com.sun.xml.ws.db.DatabindingProviderImpl.create(DatabindingProviderImpl.java:58)
at com.sun.xml.ws.db.DatabindingFactoryImpl.createRuntime(DatabindingFactoryImpl.java:130)
at com.sun.xml.ws.server.EndpointFactory.createSEIModel(EndpointFactory.java:433)
at com.sun.xml.ws.server.EndpointFactory.create(EndpointFactory.java:268)
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:145)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:569)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:552)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:623)
at org.glassfish.webservices.WSServletContextListener.registerEndpoint(WSServletContextListener.java:282)
at org.glassfish.webservices.WSServletContextListener.contextInitialized(WSServletContextListener.java:102)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4750)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:550)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5366)
at com.sun.enterprise.web.WebModule.start(WebModule.java:498)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:733)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2018)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1669)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:109)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:301)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:107)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:151)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:148)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: javax.xml.bind.JAXBException: return is not a valid property on class org.example.Wrapper
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getElementPropertyAccessor(JAXBContextImpl.java:981)
at com.sun.xml.ws.db.glassfish.JAXBRIContextWrapper.getElementPropertyAccessor(JAXBRIContextWrapper.java:121)
at com.sun.xml.ws.server.sei.EndpointResponseMessageBuilder$DocLit.<init>(EndpointResponseMessageBuilder.java:214)
... 42 more
If I add the following annotations to the method and create a wrapper class, it kinda works:
#WebMethod
#ResponseWrapper(className="org.example.Wrapper")
With these annotations, no errors on installation and I'm able to retrieve the WSDL. However, the Tester doesn't work and I get this message from my browser:
Exceptions details : java.lang.RuntimeException: Cannot find the correct port class.
javax.servlet.ServletException: java.lang.RuntimeException: Cannot find the correct port class. at
org.glassfish.webservices.monitoring.WebServiceTesterServlet.initializePort(WebServiceTesterServlet.java:572) at
org.glassfish.webservices.monitoring.WebServiceTesterServlet.doGet(WebServiceTesterServlet.java:169) at
org.glassfish.webservices.monitoring.WebServiceTesterServlet.invoke(WebServiceTesterServlet.java:104) at
org.glassfish.webservices.JAXWSServlet.doGet(JAXWSServlet.java:186) at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:770) at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542) at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281) at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) at
com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317) at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:680) Caused by: java.lang.RuntimeException:
Cannot find the correct port class. at org.glassfish.webservices.monitoring.WebServiceTesterServlet.initializePort(WebServiceTesterServlet.java:559) ... 29 more
I would rather not have to add these annotations for each method and a wrapper class just to get things to work and even doing so, still not optimal.
UPDATE: Here's the WSDL file for this:
<!-- Published by JAX-WS RI at http://jax-ws.dev.java.net. RI's version is Metro/2.2-b13 (branches/2.2-6964; 2012-01-09T18:04:18+0000) JAXWS-RI/2.2.6-promoted-b20 JAXWS/2.2 svn-revision#unknown. -->
<!-- Generated by JAX-WS RI at http://jax-ws.dev.java.net. RI's version is Metro/2.2-b13 (branches/2.2-6964; 2012-01-09T18:04:18+0000) JAXWS-RI/2.2.6-promoted-b20 JAXWS/2.2 svn-revision#unknown. -->
<definitions targetNamespace="http://example.org/" name="ExampleComponentService">
<types>
<xsd:schema>
<xsd:import namespace="http://example.org/" schemaLocation="http://localhost:8080/test-jaxws/ExampleComponentService?xsd=1"/>
</xsd:schema>
</types>
<message name="sayHello">
<part name="parameters" element="tns:sayHello"/>
</message>
<message name="sayHelloResponse">
<part name="parameters" element="tns:sayHelloResponse"/>
</message>
<portType name="ExampleComponent">
<operation name="sayHello">
<input wsam:Action="http://example.org/ExampleComponent/sayHelloRequest" message="tns:sayHello"/>
<output wsam:Action="http://example.org/ExampleComponent/sayHelloResponse" message="tns:sayHelloResponse"/>
</operation>
</portType>
<binding name="ExampleComponentPortBinding" type="tns:ExampleComponent">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<operation name="sayHello"><soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="ExampleComponentService">
<port name="ExampleComponentPort" binding="tns:ExampleComponentPortBinding">
<soap:address location="http://localhost:8080/test-jaxws/ExampleComponentService"/>
</port>
</service>
</definitions>
I'm not sure if this was your exact problem, but I had a similar exception when trying to deploy a simple test WebService. It had these exceptions at the bottom of the stack:
javax.xml.ws.WebServiceException: class com.test.AddResponse do not have a property of the name return
javax.xml.bind.JAXBException: return is not a valid property on class com.test.AddResponse
After looking at Sahoo's sample code I saw this in osgi.properties for their webservices test bundle:
# See http://java.net/jira/browse/GLASSFISH-16551 as to why the WAB needs to import JAXB classes
DynamicImport-Package=javax.xml.bind, javax.xml.bind.*
The link explains why the problem happens and that to work around it you may include those packages as dynamic imports.
I know that is no solution to your problem, but maybe you could have a look an http://cxf.apache.org/. CXF is a service framework specially for SOAP/REST webservices and works great with OSGi. Maybe this could solve your problems.
Related
I have upgraded a Spring boot service to Infinispan 9.4.16.Final from 5.2.20.Final. The service has two XML files. I used the conversion script to convert them. Both have local-cache entries and no other types of caches. One was left with empty transport element by the conversion tool.
When we deploy and run these services, we often see this warning at startup:
org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.globalstate.impl.GlobalConfigurationManagerImpl.start() on object of type GlobalConfigurationManagerImpl
The above is the first warning/error we see. There is no stack trace. Why would it be calling GlobalConfigurationManagerImpl when we're only using local cache?
A few lines later in the log, then I see many The cache has been stopped and invocations are not allowed! errors. The last error we see is as follows. The service fails to start up successfully.
Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache org.infinispan.CONFIG on <server_name>
Why are these errors/warnings happening on startup? Is there a problem in the config files? I've searched online and have not found a solution.
~~More Info~~~
Here is one of the two XML config files:
<infinispan
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation = "urn:infinispan:config:9.4 http://www.infinispan.org/schemas/infinispan-config-9.4.xsd"
xmlns = "urn:infinispan:config:9.4">
<threads/>
<cache-container name = "TestCenterServiceCache">
<!-- The conversion tool added this empty "transport" element. It was not present in our old config file -->
<transport/>
<jmx domain = "org.infinispan.TestCenterServiceCache"/>
<local-cache name = "authorizedLocations">
<expiration lifespan = "3600000"/>
</local-cache>
<!--caching for 24 hours: 3,600,000 milliseconds/hr x 24 hours -->
<local-cache name = "proximitySearchConfiguration">
<expiration lifespan = "86400000"/>
</local-cache>
</cache-container>
</infinispan>
The above is instantiated via applicationContext.xml. The first warning (GlobalConfigurationManagerImpl.start()) is referencing these beans.
<bean id="infinispanCacheManager"
class="org.infinispan.spring.embedded.support.InfinispanEmbeddedCacheManagerFactoryBean"
p:configurationFileLocation="classpath:testCenterServices-cache-config.xml" />
<bean id="cacheManager"
class="org.infinispan.spring.embedded.provider.SpringEmbeddedCacheManager">
<constructor-arg ref="infinispanCacheManager" />
</bean>
Here is the second XML config file:
<?xml version="1.0" ?>
<infinispan
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation = "urn:infinispan:config:9.4 http://www.infinispan.org/schemas/infinispan-config-9.4.xsd"
xmlns = "urn:infinispan:config:9.4">
<threads />
<cache-container name="AtlasServicesCacheManager">
<local-cache name="allLocaleCache" />
<local-cache name="localeCacheByID" />
<local-cache name="countryByCode" />
<local-cache name="allActiveCountries" />
<local-cache name="allCountries" />
<local-cache name="allStatesForCountryCode" />
<local-cache name="allActiveStatesForCountryCode" />
<local-cache name="stateForCountryCodeStateCode" />
</cache-container>
</infinispan>
The above is instantiated via java code.
#Bean(name="atlasServicesCacheManager")
public CacheManager makeCacheManager() throws IOException {
return new SpringEmbeddedCacheManager(new DefaultCacheManager("atlas-cache-config.xml"));
}
I don't know if it's meaningful, but only after the upgrade, we log messages that include "JGroups", such as Unable to use any JGroups configuration mechanisms provided in properties {}. Using default JGroups configuration!.
The service instances are running on Windows Server 2012 R2 Standard (Windows 8).
To fix this, remove the empty <transport /> element for local caches.
Adding that empty element seems to be a defect in the config-converter. With the empty transport element in place, it seems that Infinispan is partially configured for cluster synchronization. For details on the underlying issue, see bug report: https://issues.redhat.com/browse/ISPN-11854.
How can I generate from a Java Web Service class a WSDL-file, which is supported by Sudzc.com to generate a Objective-C code?
I tried it with a simple example.
My Java Web Service class:
package main;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.WebService;
#WebService(name="RectangleWebService", serviceName = "RectangleWebService", portName = "RectangleWebServicePort", targetNamespace = "http://www.mywstest.com/ws/rectangle")
public class RectangleService {
#WebMethod(action="calculateValueOne")
public #WebResult(name="ValueOne") float calculateValueOne(#WebParam(name="Length") float length, #WebParam(name="Width")float width){
return 2*(length+width);
}
#WebMethod(action="calculateValueTwo")
public #WebResult(name="ValueTwo") float calculateValueTwo(#WebParam(name="Length") float length, #WebParam(name="Width")float width){
return (length*width);
}
}
I create a WSDL-file with an ant-script and wsgen and then I uploaded it on http://sudzc.com to create the Objective-C code (Objective-C for iOS with ARC). My Problem is that the created Objective-C code from Sudzc.com has no instance Methods...
This is my WSDL-file:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Generated by JAX-WS RI at http://jax-ws.dev.java.net. RI's version is JAX-WS RI 2.1.6 in JDK 6. -->
<definitions targetNamespace="http://www.mywstest.com" name="RectangleWebService" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://www.mywstest.com" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
<import namespace="http://www.mywstest.com/ws/rectangle" location="RectangleWebServicePortType.wsdl"/>
<binding name="RectangleWebServicePortBinding" type="ns1:RectangleWebService" xmlns:ns1="http://www.mywstest.com/ws/rectangle">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<operation name="calculateValueOne">
<soap:operation soapAction="calculateValueOne"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
<operation name="calculateValueTwo">
<soap:operation soapAction="calculateValueTwo"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="RectangleWebService">
<port name="RectangleWebServicePort" binding="tns:RectangleWebServicePortBinding">
<soap:address location="REPLACE_WITH_ACTUAL_URL"/>
</port>
</service>
</definitions>
When I use the WSDL-file from http://www.w3schools.com/webservices/tempconvert.asmx?WSDL to generate the Objective-C code with sudzc.com, it works fine and I can use the instance methods
of the web service in my Objective-C project... !!!
Perhaps someone can help?
P.S. Sorry for my bad english and I am an absolute beginner in web services...
That sudzC has a lot of issues with memory, I use WSClient++ to generate the classes and never had a problem.
http://wsclient.neurospeech.com/
The problem is that the generated RectangleWebService.wsdl file has a schema import from an external schema1.xsd file...
So i have to create one wsdl-file and then it should work with sudzc.com...
Is my guess right?
I'm hosting a WCF Web Service with the following WSDL (a simple service using wsHttpBinding and SSL for transport security):
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex" xmlns:wsa10="http://www.w3.org/2005/08/addressing" xmlns:tns="http://tempuri.org/" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" name="MagicEightBallService" targetNamespace="http://tempuri.org/">
<wsp:Policy wsu:Id="WSHttpBinding_TransportSecurity_IMagicEightBallService_policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:TransportBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken RequireClientCertificate="false"/>
</wsp:Policy>
</sp:TransportToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict/>
</wsp:Policy>
</sp:Layout>
</wsp:Policy>
</sp:TransportBinding>
<wsaw:UsingAddressing/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<wsdl:types>
<xsd:schema targetNamespace="http://tempuri.org/Imports">
<xsd:import schemaLocation="http://my.local.domain.name/MagicEightBall/MagicEightBallService.svc?xsd=xsd0" namespace="http://tempuri.org/"/>
<xsd:import schemaLocation="http://my.local.domain.name/MagicEightBall/MagicEightBallService.svc?xsd=xsd1" namespace="http://schemas.microsoft.com/2003/10/Serialization/"/>
</xsd:schema>
</wsdl:types>
<wsdl:message name="IMagicEightBallService_GetAdvice_InputMessage">
<wsdl:part name="parameters" element="tns:GetAdvice"/>
</wsdl:message>
<wsdl:message name="IMagicEightBallService_GetAdvice_OutputMessage">
<wsdl:part name="parameters" element="tns:GetAdviceResponse"/>
</wsdl:message>
<wsdl:portType name="IMagicEightBallService">
<wsdl:operation name="GetAdvice">
<wsdl:input wsaw:Action="http://tempuri.org/IMagicEightBallService/GetAdvice" message="tns:IMagicEightBallService_GetAdvice_InputMessage"/>
<wsdl:output wsaw:Action="http://tempuri.org/IMagicEightBallService/GetAdviceResponse" message="tns:IMagicEightBallService_GetAdvice_OutputMessage"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="WSHttpBinding_TransportSecurity_IMagicEightBallService" type="tns:IMagicEightBallService">
<wsp:PolicyReference URI="#WSHttpBinding_TransportSecurity_IMagicEightBallService_policy"/>
<soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="GetAdvice">
<soap12:operation soapAction="http://tempuri.org/IMagicEightBallService/GetAdvice" style="document"/>
<wsdl:input>
<soap12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="MagicEightBallService">
<wsdl:port name="WSHttpBinding_TransportSecurity_IMagicEightBallService" binding="tns:WSHttpBinding_TransportSecurity_IMagicEightBallService">
<soap12:address location="https://localhost/MagicEightBall/MagicEightBallService.svc"/>
<wsa10:EndpointReference>
<wsa10:Address>
https://localhost/MagicEightBall/MagicEightBallService.svc
</wsa10:Address>
</wsa10:EndpointReference>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Why do I get errors when I try to consume this from Java? When I try to consume it using Axis2/Java, I get the error:
org.apache.axis2.AxisFault: Must Understand check failed for header http://www.w3.org/2005/08/addressing : Action
And when I try to use JAX-WS, I get the error:
javax.xml.ws.soap.SOAPFaultException: MustUnderstand headers:[{http://www.w3.org/2005/08/addressing}Action] are not understood
So far I haven't had any success with either of these, and I'm not sure whether a fix needs to be applied to the server or the client.
(See a related question I posted for more details, including the WCF Web.config).
Running:
ServiceClient sc = stub._getServiceClient();
sc.engageModule("addressing");
engages the Addressing module, fixing this issue.
I know the post is old, but someone may still face this problem.
I'm using JAX-WS, and I was having the same issue. After reading https://jax-ws.java.net/jax-ws-21-ea3/docs/wsaddressing.html#On_the_client_side I've found a solution that worked for me.
The code was breaking in the following line:
IFooService service = new FooService().getWSHttpBindingIFooService();
What I've done is the following:
IFooService service = new FooService().getWSHttpBindingIFooService(new javax.xml.ws.soap.AddressingFeature());
That's it.
also add addressing.mar and soapmonitor.mar to your library path.
I too had the same problem.
In my case the webservice's WSDL was created using WCF in .net and we are consuming it at JAVA side. After several tries I noticed that the corresponding header was missing in the web service. I asked my dotnet team to add a - port name in the webservice.This port name just a normal name in the web service. This was needed because at JAVA side we need port type and port name to actually access the webservice.
Try to add below lines at the .net side inside the service and then try to consume at JAVA side.
[ServiceContract(Namespace = "BookStockWebService", Name = "BookStock")]
[ServiceBehavior(Namespace = "BookStockWebServiceport", Name = "BookStockPort")]
If client has been generated using Apache CXF and facing this issue, then below helps:
Add below annotation to IService interface:
#Addressing(enabled=true, required=false)
In client class that is where the service is being obtained for calling:
ServiceImpl service = new ServiceImpl(wsdl,service); IService port = service.getWSHttpBindingIService(new AddressingFeature(true));
Import for AddressingFeature is javax.xml.ws.soap.AddressingFeature;
Anyone know why this wsdl is not liked by the mono wsdl tool? Microsoft parses it. XMethods online wsdl validator parses it. Mono just doesn't seem to like it and I do not know enough to understand why.
# the error
mmcaughan#mmcaughan-dsktop:~/Projects/sftest$ wsdl enterprise.wsdl
Web Services Description Language Utility
Mono Framework v2.0.50727.1433
There where some warnings while generating the code:
enterprise.wsdl
- This web reference does not conform to WS-I Basic Profile v1.1
R2718: A wsdl:binding in a DESCRIPTION MUST have the same set of
wsdl:operations as the wsdl:portType to which it refers.
* Binding 'SoapBinding', in Service Description
'urn:enterprise.soap.sforce.com'
Writing file 'SforceService.cs'
relevant WSDL parts (I think)
<!-- Soap PortType -->
<portType name="Soap">
<operation name="login">
<documentation>Login to the Salesforce.com SOAP Api</documentation>
<input message="tns:loginRequest"/>
<output message="tns:loginResponse"/>
<fault message="tns:LoginFault" name="LoginFault"/>
<fault message="tns:UnexpectedErrorFault" name="UnexpectedErrorFault"/>
<fault message="tns:InvalidIdFault" name="InvalidIdFault"/>
</operation>
<!-- Soap Binding -->
<binding name="SoapBinding" type="tns:Soap">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="login">
<soap:operation soapAction=""/>
<input>
<soap:header use="literal" message="tns:Header" part="LoginScopeHeader"/>
<soap:body parts="parameters" use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
<fault name="LoginFault">
<soap:fault name="LoginFault" use="literal"/>
</fault>
<fault name="UnexpectedErrorFault">
<soap:fault name="UnexpectedErrorFault" use="literal"/>
</fault>
<fault name="InvalidIdFault">
<soap:fault name="InvalidIdFault" use="literal"/>
</fault>
</operation>
Older and more wiser now...
generate the C# from the wsdl
wsdl enterprise.wsdl -n:Sforce -o:SforceService.cs
the XmlAnyElement cannot have an empty namspace, so pop open SforceService.cs and remove it
this...
[System.Xml.Serialization.XmlAnyElement(Namespace="")]
public System.Xml.XmlElement[] Any {
get {
return this.anyField;
}
set {
this.anyField = value;
}
}
becomes...
public System.Xml.XmlElement[] Any {
get {
return this.anyField;
}
set {
this.anyField = value;
}
}
wsdl generates xml serialization against private members which doesn't work and has to be fixed
Unhandled Exception: System.InvalidOperationException: Member LoginScopeHeaderValueField not found in class Sforce.SforceService.
this...
[System.Web.Services.Protocols.SoapHeaderAttribute("LoginScopeHeaderValueField")]
becomes...
[System.Web.Services.Protocols.SoapHeaderAttribute("LoginScopeHeaderValue")]
search and replace ValueField" for ValueField"
then you might get this, which is a failure because mono does not install any root certificates in the trust store so https fails
Unhandled Exception: System.Net.WebException: Error writing request: The authentication or decryption has failed.
at System.Net.WebConnectionStream.WriteHeaders () [0x00000]
at System.Net.WebConnectionStream.SetHeaders (System.Byte[] buffer) [0x00000]
at (wrapper remoting-invoke-with-check) System.Net.WebConnectionStream:SetHeaders (byte[])
at System.Net.HttpWebRequest.SendRequestHeaders (Boolean propagate_error) [0x00000]
it is fixed with mozroots which will get all the certs mozilla ships with...
mozroots --import --sync
then everything works as describe
Sforce.SforceService binding = new Sforce.SforceService();
Sforce.LoginResult loginResult = binding.login("someuser", "somepass");
etc...
We've observed that when we expose a WCF service which uses classes decorated with various xml serialisation attributes, despite the fact that we use the XmlSerializerFormat attribute on the interface any XmlRoot attribute on any of the operation's parameters gets completely ignored.
The namespace of the parameters is always that of the service and not what we specify.
This is causing us problems as it does not seem to be backwards compatible with ASMX and also because we're using BizTalk, and need to have tighter control over the shape of the XML's exchanged.
A few questions then -
Anybody knows what is the rationale
behind this decision?
Anybody knows
how this is happening? I was under
the impressions that WCF, with the
XmlSerializerFormat attribute, uses
the XmlSerialiser to serialise the
types, which would suggest XmlRoot
should be taken into account, how
come this is not the case? (is it
only due to the fact that, taking
the SOAP envelope into account, the
parameter is not root?)
Most
importantly - anybody knows if
there's a way to 'force the issue' -
i.e. get the parameters to be of the
namespace of our choosing?
I've seen this post, but I don't believe it is relevant to my question -
As per Wagner Silveira's request - the contracts I used to test this are -
[ServiceContract(Namespace = "http://servicecontract"),
XmlSerializerFormat(Style = OperationFormatStyle.Document)]
public interface ITestService
{
[OperationContract]
MyOtherType MyTestMethod(MyType obj);
}
// Composite class for DCS and XMLS
[Serializable, XmlType, XmlRoot(Namespace = "http://datacontract")]
public class MyType
{
[XmlAttribute]
public string StringValue { get; set; }
}
// Composite class for DCS and XMLS
[Serializable, XmlType, XmlRoot(Namespace = "http://datacontract")]
public class MyOtherType
{
[XmlAttribute]
public string OtherStringValue { get; set; }
}
I assume you're using SOAP as the message format. In this case, the object you're serializing is not the root of the XML, the soap envelope is. So it makes sense that the XmlRoot would be ignored. By default WCF will create a message contract for you and name the response and it has the namespace of the service. What you can do is create your own message contract to have full control over SOAP.
Create the following two classes:
[MessageContract]
public class MyTestMethodRequest
{
[MessageBodyMember( Namespace = "http://datacontract" )]
public MyType MyType;
}
[MessageContract]
public class MyTestMethodResponse
{
[MessageBodyMember( Namespace = "http://datacontract" )]
public MyOtherType MyOtherType;
}
Then change the signature of your service operation to the following.
[OperationContract]
public MyTestMethodResponse MyTestMethod( MyTestMethodRequest request )
{
return new MyTestMethodResponse {
MyOtherType = new MyOtherType {
OtherStringValue = "bar"
}
};
}
Now if you example the SOAP messages you should see the following:
Request
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none"
s:mustUnderstand="1">http://servicecontract/TestService/MyTestMethod</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<MyTestMethodRequest xmlns="http://servicecontract">
<MyType StringValue="foo" xmlns="http://datacontract" />
</MyTestMethodRequest>
</s:Body>
</s:Envelope>
Response
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header />
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<MyTestMethodResponse xmlns="http://servicecontract">
<MyOtherType OtherStringValue="bar" xmlns="http://datacontract" />
</MyTestMethodResponse>
</s:Body>
</s:Envelope>
I don't know why WCF ignores XmlRoot, so I can't answer that part of your question. But I do have a couple ways to solve the problem.
start with WSDL first.
If you have a particular set of XML namespaces you would like to apply to the messages that get sent and receieved, use WSDL and XML Schema to explicitly specify them.
Then, generate the Server-side stub code, or the client-side proxy code, directly from that WSDL via the svcutil.exe tool.
use a custom ServiceHost
The other option open to you, described at this link, is to use a custom ServiceHost that overrides WCF's decision to disregard the XmlRoot or XmlType attributes on message types.
If you choose to go for the WSDL-First approach, the WSDL should look like this:
<?xml version="1.0" encoding="utf-8" ?>
<definitions
xmlns="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="urn:The-Service-namespace"
xmlns:tns="urn:The-Service-namespace"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:n0="urn:The-Request-namespace"
xmlns:n1="urn:The-Response-namespace"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
elementFormDefault= "unqualified"
>
<types>
<s:schema targetNamespace="urn:The-Request-namespace" >
<s:complexType name="Type1">
<s:sequence>
<s:element name="x" minOccurs="1" maxOccurs="1" type="s:string"/>
</s:sequence>
</s:complexType>
<s:element name="Type1" type="n0:Type1" />
</s:schema>
<s:schema targetNamespace="urn:The-Response-namespace" >
<s:complexType name="Type2">
<s:sequence>
<s:element name="x" minOccurs="1" maxOccurs="1" nillable="false" type="s:string"/>
<s:element name="y" minOccurs="1" maxOccurs="1" nillable="false" type="s:int"/>
<s:element name="z" minOccurs="1" maxOccurs="1" nillable="false" type="s:boolean" />
</s:sequence>
</s:complexType>
<s:element name="Type2" type="n1:Type2" />
</s:schema>
</types>
<message name="RequestMessage">
<part name="inPart1" element="n0:Type1" />
</message>
<message name="ResponseMessage">
<part name="outPart1" element="n1:Type2" />
</message>
<portType name="PortTypeName">
<operation name="Method1">
<input message="tns:RequestMessage" />
<output message="tns:ResponseMessage" />
</operation>
</portType>
<binding name="InterfaceName" type="tns:PortTypeName">
<soap:binding
transport="http://schemas.xmlsoap.org/soap/http"
style="rpc" />
<operation name="Method1">
<soap:operation soapAction="" style="document" />
<input> <soap:body use="literal" /> </input>
<output> <soap:body use="literal" /> </output>
</operation>
</binding>
</definitions>
This WSDL is very simple - it defines a single operation, with a single request message and a single response message.
Notice there are three xml namespaces:
urn:The-Service-namespace
used for the element that wraps the request and response - the first element inside the <SOAP:body>
urn:The-Request-namespace
used for the element wrapped inside that request wrapper, which gets deserialized into an instance of Type1.
urn:The-Response-namespace
used for the element wrapped inside that response wrapper, which gets deserialized into an instance of Type2.
If your web services interface is more complicated, has more operations and consequently more request and response message types, you can add more namespaces, if you like, for all those additional types.