I'm deploying a StatelessSessionBean annotated with #WebService to JBoss. I'm taking the WSDL generated by JBoss to generate client stubs. My problem is in calling a method which returns a list of objects. If the list is empty the call succeeds however if the list is not empty then I get the following exception:
com.sun.xml.ws.encoding.soap.DeserializationException: Failed to read a response: javax.xml.bind.UnmarshalException
- with linked exception:
[javax.xml.bind.UnmarshalException: Unable to create an instance of com.companyname.api.ws.DataItemType
- with linked exception:
[java.lang.InstantiationException]]
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:124)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118)
at $Proxy34.getWorkflows(Unknown Source)
at com.companyname.api.SimpleClient.go(SimpleClient.java:48)
Searching the web led me to this discussion here: http://forums.java.net/jive/message.jspa?messageID=281780
However I have set the #XmlSeeAlso stuff correctly and it is present on the generated stub classes. I can confirm that the DataItemType class is abstract so it is not surprising that an attempt to instantiate it causes a problem. I'm not at all clear on why the DataItemType class is being instantiated at all (as it is abstract). This is the XML that is returned from the server (it looks about right to me):
<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
<env:Header></env:Header>
<env:Body>
<ns2:getWorkflowsResponse xmlns:ns2="http://ws.api.companyname.com/">
<return>
<id>
<identifier>1</identifier>
<version>0</version>
</id>
<goal>ENROLL</goal>
<dataItemType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="DataItemTypeText">
<attributeName>email</attributeName>
<displayName>Email Address</displayName>
</dataItemType>
...
</return>
</ns2:getWorkflowsResponse>
</env:Body>
</env:Envelope>
Does anyone know what I'm doing wrong?
There were a number of issues with the generated WSDL (note that it wasn't a handcrafted one). There was nothing specific that I changed which indicated why this particular exception was thrown (or why, for example, there wasn't a failure when generating the incorrect WSDL).
Once I adjusted the annotations so that a valid WSDL was created then I had further issues which the JAX-WS versions I was using. I ended up upgrading the version used by JBoss which, in turn, led to me needing put the newer JAX-WS jars in my JRE endorsed directory.
I'm not going to detail what I did in any more detail as there was no specific thing that I did that addressed this problem. If anyone else sees it I would suggest being very specific in the annotations you use to generate your WSDL and taking a careful look at your WSDL.
Related
I have an issue when deploying my CXF project to JBoss EAP 6.4 that does NOT seem to be covered by other people asking about this issue.
I am receiving the following stack trace when I attempt to deploy:
14:02:08,701 ERROR [org.springframework.web.context.ContextLoader] (ServerService Thread Pool -- 119) Context initialization failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'AdminServices': Invocation of init method failed; nested exception is javax.xml.ws.WebServiceException: org.apache.cxf.service.factory.ServiceConstructionException
(snip)
Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.service.factory.ServiceConstructionException
(snip)
Caused by: org.apache.cxf.service.factory.ServiceConstructionException
at org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:329) [cxf-rt-databinding-jaxb-3.1.13.jar:3.1.13]
at org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86) [cxf-core-3.1.13.jar:3.1.13]
at org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:470) [cxf-rt-wsdl-3.1.13.jar:3.1.13]
at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:696) [cxf-rt-frontend-jaxws-3.1.13.jar:3.1.13]
at org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:530) [cxf-rt-wsdl-3.1.13.jar:3.1.13]
at org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:263) [cxf-rt-wsdl-3.1.13.jar:3.1.13]
at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199) [cxf-rt-frontend-jaxws-3.1.13.jar:3.1.13]
at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103) [cxf-rt-frontend-simple-3.1.13.jar:3.1.13]
at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168) [cxf-rt-frontend-simple-3.1.13.jar:3.1.13]
at org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211) [cxf-rt-frontend-jaxws-3.1.13.jar:3.1.13]
at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:460) [cxf-rt-frontend-jaxws-3.1.13.jar:3.1.13]
at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:338) [cxf-rt-frontend-jaxws-3.1.13.jar:3.1.13]
... 32 more
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 208 counts of IllegalAnnotationExceptions
Two classes have the same XML type name "{http://app.application.com/adminServices}addCatalog". Use #XmlType.name and #XmlType.namespace to assign different names to them.
(sample)
Two classes have the same XML type name "{http://app.application.com/adminServices}updateQuantityAllocationResponse". Use #XmlType.name and #XmlType.namespace to assign different names to them.
this problem is related to the following location:
at com.jason.app.control.jaxws_asm.UpdateQuantityAllocationResponse
this problem is related to the following location:
at com.jason.app.adminservices.UpdateQuantityAllocationResponse
at public javax.xml.bind.JAXBElement com.jason.app.adminservices.ObjectFactory.createUpdateQuantityAllocationResponse(com.jason.app.adminservices.UpdateQuantityAllocationResponse)
at com.jason.app.adminservices.ObjectFactory
I do NOT recognize the com.jason.app.control.jaxws_asm package, and it does not exist in the EAR file I am deploying. This implies to me that JBoss is doing something, but I have no idea what.
My jboss-deployment-structure.xml is simple, only excluding the built-in webservices subsystem since I am using a more modern version of CXF.
<?xml version="1.0" encoding="UTF-8"?> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"> <ear-subdeployments-isolated>false</ear-subdeployments-isolated> <deployment> <exclude-subsystems> <subsystem name="webservices" /> </exclude-subsystems> </deployment> </jboss-deployment-structure>
I am totally stumped on this issue. If anyone can help, I would appreciate. I will post more information if requested.
I assume you have this class defined:
at com.jason.app.adminservices.UpdateQuantityAllocationResponse
In your WS, you probably have a method that contains something like this:
#WebMethod //exposed as operation in your WS
#ResponseWrapper(localName = "UpdateQuantityAllocation") //this is the wrapper element in the response
CXF/JAXB generates this class:
at com.jason.app.control.jaxws_asm.UpdateQuantityAllocationResponse
Thus you end up with 2 classes having same name.
Happened the same to me, in my case, i copy-pasted the generated client classes from another project (for the same WS), but the package was different.
IDE automatically fixed the package from JAVA headers, but didn't changed the string in #ResponseWrapper attributes.
I am using CXF JAXWS Client for retrieving some information from an external web services. So, basically, we have .xsd and .wsdl files from the external and try to implement our ws consumer by generating the client stubs using cxf-codegen-plugin. We cannot change the .xsd and .wsdl files. Everything works fine, we are able to send and retrieve soap messges from the external services.
However, when I look into the soap request message from the log, I find a lot of unused namespaces in the soap (body) message sent from our ws client.
Below is an example
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:aheaderns="http://xxx.xxx.xxx.xxx/header.xsd">
<soap:Header>
...
</soap:Header>
<soap:Body>
<ns7:requestQuery xmlns:ns15="http://xxx.xxx.xxx.xxx/AAA" xmlns:ns14="http://xxx.xxx.xxx.xxx/BBB" xmlns:ns13="http://xxx.xxx.xxx.xxx/DDD" xmlns:ns12="http://xxx.xxx.xxx.xxx/CCC" xmlns:ns11="http://xxx.xxx.xxx.xxx/EEE" xmlns:ns10="http://xxx.xxx.xxx.xxx/FFF" xmlns:ns9="http://xxx.xxx.xxx.xxx/GGG" xmlns:ns8="http://xxx.xxx.xxx.xxx/HHH" xmlns:ns7="http://xxx.xxx.xxx.xxx/III" xmlns:ns6="http://xxx.xxx.xxx.xxx/JJJ" xmlns:ns5="http://xxx.xxx.xxx.xxx/KKK">
<ns7:sample>
<ns7:type>A</ns7:type>
<ns7:ref>1</ns7:ref>
</ns7:sample>
</ns7:requestQuery>
</soap:Body>
Is there any way to remove the unused namespaces from the outbound soap message sending from the client?
You could move your client proxy classes to the same package and map it to the proposed namespace specified in the wsdl.
Put this code into the package-info.java class:
#XmlSchema(xmlns = { #XmlNs(prefix = "ns1", namespaceURI = "http://xxx.xxx.xxx") },
namespace = "http://xxx.xxx.xxx")
package clinet.sample.proxy;
import javax.xml.bind.annotation.XmlNs;
Hope this helps.
After digging into this problem for quite sometime, I found the solution. However, I think my solution is not to solve the problem at the root cause but it works for now.
Basically, I use XSLTOutInterceptor from CXF to apply the XSL to the out message. However, the default PRE_STEAM phase is not working for me. Then, I decide to extend the XSLTOutInterceptor so as to change its PHASE to WRITE. So that, the unused namespaces will be removed during the writing of the protocol message before sending it out.
The XSL I use is from how to remove unused namespaces from source xml
By the way, I still have no idea why those unused namespaces have been generated. If anyone could give me a suggestion, I would appreciate it.
Thanks :)
I'm calling a .Net Web Service which takes a complex type as a parameter (using KSoap2). I've done this before successfully so I decided to just copy my old code and paste it into a new method, replacing some code with code relevant to the current web service of course.
The only real difference I can see is that the URL to the new web service's .asmx is different.
The thing is I keep getting the following error:
(I get the following when SoapEnvelope.VER11)
org.xmlpull.v1.XmlPullParserException: expected: END_TAG {http://schemas.xmlsoap.org/soap/envelope/}Body (position:END_TAG </{http://schemas.xmlsoap.org/soap/envelope/}soap:Fault>#1:338 in java.io.InputStreamReader#199cb474)
(And the following when SoapEnvelope.VER12)
org.xmlpull.v1.XmlPullParserException: expected: START_TAG {http://www.w3.org/2001/12/soap-envelope}Envelope (position:START_TAG <{http://schemas.xmlsoap.org/soap/envelope/}soap:Envelope>#1:207 in java.io.InputStreamReader#5b209e72
Why would the error message change like this depending on the version of SOAP I use?
I also tried printing out my envelope with HttpTransport.requestDump and I get the following:
xmlns:v="http://schemas.xmlsoap.org/soap/envelope/">
<v:Header />
<v:Body>
<postMessage xmlns="http://www.magnatech.com/" id="o0" c:root="1">
<myMessage i:type="n0:Message" xmlns:n0="http://www.magnatech.com/">
<messageContent i:type="d:string">HEY</messageContent>
<userName i:type="d:string">TEST USERNAME</userName>
<agentName i:type="d:string">TEST AGENT NAME</agentName>
<userID i:type="d:string">0</userID>
<agentID i:type="d:string">0</agentID>
<fromAgent i:type="d:string">false</fromAgent>
<messageID i:type="d:string"></messageID>
<accountNumber i:type="d:string">TEST ACCOUNT</accountNumber>
</myMessage>
</postMessage>
</v:Body>
Which looks fine, I actually did the same thing with the envelope from my other "WORKING" web service call and they are the same, except for the element names of course.
And finally, here is the output from HttpTransport.responseDump:
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode>soap:Client</faultcode><faultstring>Could not deserialize Soap message</faultstring></soap:Fault></soap:Body></soap:Envelope>
So obviously there is something wrong with the envelope as I'm sending it, yet I see nothing wrong with it.
What could be the problem? I've tried everything possible and am running out of ideas.
Any help at all will be greatly appreciated.
Thanks
I am attempting to use Metro web services in place of the default Weblogic webservices stack contained in weblogic.jar.
The problem comes when trying to get WebLogic to use the metro stack before its own.
The steps I have taken so far is to reference the webservices-rt.jar in the project. So far I am getting this error while deploying the ear file....
Caused By: java.lang.LinkageError: loader constraint violation: when resolving field "DATETIME" the class loader (instance of weblogic/utils/classloaders/ChangeAwareClassLoader) of the referring class, javax/xml/datatype/DatatypeConstants, and the class loader (instance of ) for the field's resolved type, javax/xml/namespace/QName, have different Class objects for that type
UPDATES:
Most Recent Error is: "class javax.xml.namespace.QName has neither #WebSerivce nor #WebServiceProvider" Strange that it is looking for #Webservice on a QName object:
Contents of Application-Weblogic.xml
<wls:prefer-application-packages>
<wls:package-name>com.ctc.</wls:package-name>
<wls:package-name>com.sun.xml.</wls:package-name>
<wls:package-name>com.sun.istack.</wls:package-name>
<wls:package-name>com.sun.msv.datatype.</wls:package-name>
<wls:package-name>com.sun.msv.driver.</wls:package-name>
<wls:package-name>com.sun.msv.grammar.</wls:package-name>
<wls:package-name>com.sun.msv.reader.</wls:package-name>
<wls:package-name>com.sun.msv.relaxns.</wls:package-name>
<wls:package-name>com.sun.msv.scanner.</wls:package-name>
<wls:package-name>com.sun.msv.util.</wls:package-name>
<wls:package-name>com.sun.msv.verifier.</wls:package-name>
<wls:package-name>com.sun.msv.writer.</wls:package-name>
<wls:package-name>com.sun.org.apache.xml.internal.</wls:package-name>
<wls:package-name>com.sun.wsit.</wls:package-name>
<wls:package-name>javax.jws.</wls:package-name>
<wls:package-name>javax.xml.bind.</wls:package-name>
<wls:package-name>javax.xml.soap.</wls:package-name>
<wls:package-name>javax.xml.stream.</wls:package-name>
<wls:package-name>javax.xml.ws.</wls:package-name>
<wls:package-name>javax.xml.activation.</wls:package-name>
<wls:package-name>javax.xml.annotation.</wls:package-name>
<wls:package-name>javax.xml.mail.</wls:package-name>
<wls:package-name>javax.xml.security.</wls:package-name>
<wls:package-name>javax.xml.registry.</wls:package-name>
<wls:package-name>javax.xml.rpc.</wls:package-name>
<wls:package-name>javax.xml.crypto.</wls:package-name>
<wls:package-name>javanet.staxutils.</wls:package-name>
<wls:package-name>jp.gr.xml.</wls:package-name>
<wls:package-name>org.codehaus.stax2.</wls:package-name>
<wls:package-name>org.glassfish.gmbal.</wls:package-name>
<wls:package-name>org.iso_relax.</wls:package-name>
<wls:package-name>org.jcp.xml.dsig.</wls:package-name>
<wls:package-name>org.jvnet.</wls:package-name>
<wls:package-name>org.relaxng.</wls:package-name>
<wls:package-name>antlr.</wls:package-name>
<wls:package-name>org.apache.commons.lang.</wls:package-name>
</wls:prefer-application-packages>
Take a look at using the FilteringClassLoader which is configured in weblogic-application.xml deployment descriptor. You can instruct WebLogic to load classes from the application in favor of the libraries that are included with WebLogic. The descriptor element is and you specify the Java packages you want to load from the application.
If you are using WebLogic 10.3.4 you can use the ClassLoader Analysis to analyze the packages that are in conflict.
Check out my presentation here: SlideShare.net and my demo of the CAT here: YouTube
I'm testing JAX-WS to access the Oracle IRM web serviecs. I can get it to work just fine with AXIS so this isn't an Oracle problem.
What's happening is that I'm getting the following error when making the call:
Expected xsd:anyType - unknown type provided
If I look at the SOAP packet is sent I see that the owner tag is blank under JAX-WS:
<ns1:browseAccounts>
<owner/>
<accountType>All</accountType>
</ns1:browseAccounts>
The same piece under AXIS is this:
<owner xsi:type="ns1:LicenseServer"
xmlns=""
xmlns:ns1="http://www.sealedmedia.com/ls/server/schema">
<serverKey>#############</serverKey>
</owner>
Obviously the owner tag is not getting properly created, this is what I'm using to create that:
AccountServicesPort AA = ORI.getAccountServices();
LicenseServer LicSer = new LicenseServer();
LicSer.setServerKey("#######################");
List<Account> Acts = AA.browseAccounts(LicSer,AccountAccountType.ALL);
Is there some other process that I need to go through to create the object properly?
EDIT
I thought maybe running the LicenseServer creation through ObjectFactory would help. Unfortunately, it doesn't.
Despite the Oracle IRM documentation stating that BrowseAccounts accepts either a LicenseServer object or a Context object for the owner parameter it actually accepts an LicenseServer_ref.
EDIT
Further, I was running JAX-WS under JDK 1.6.0 which is a lower version than JDK 1.6.0_14. The new version supports XMLSeeAlso annotation which allowed JAX-WS to use the proper class for serialization.