We Keep Coding

java.lang.ClassCastException: oracle.j2ee.ws.saaj.soap.TextImpl cannot be cast to javax.xml.soap.SOAPElement

I get this java.lang.ClassCastException by trying to communicate with my Webservice which has SOAPHeader Handler implimentation.
The error occurs by
String data= ((Text) ((SOAPElement) is.next()).getChildElements().next()).getValue();
in the incomming method this class "oracle.j2ee.ws.saaj.soap.TextImpl"
I can not explain from where it comes i didn't bind it anywhere
NOTE
1. I'am using Weblogic Server 12c
2. I search after TextImpl class in the hole server but no result
May be somebody faces already this issue?
Thanks for your help

I had similar problem when i deployed my web service into IBM WAS7.0 and tested through SOAP UI. After so much of google search i came to know the root case
"issue was that whitespace in the header was incorrectly being cast to a SOAPElement which resulted in the ClassCastException."
After removed the white space in the SOAP request, it worked.
Refer the link for more information http://www-01.ibm.com/support/docview.wss?uid=swg1PK90295
Check if there is a similar issue in WebLogic too.

Calling web service that sits on a load balancer with jax-ws returns at http status of 302, but when I use SoapUI it works fine

When I call a web service that sits on a load balancer with jax-ws, it returns
The server sent HTTP status code 302: Moved Temporarily
and then fails, but when I use SoapUI it works fine.
Is there a way that I can configure the service to handle this correctly?
I generated the webservice code using wsimport and make the call as such
NotificationWebService service = new NotificationWebService(wsdlLocation, qName);
NotificationWebServiceSoap serviceSoap = service.getNotificationWebServiceSoap();
String xmlString = serviceSoap.getRSAPublicKeyXMLString();
I'm stuck and I haven't been able to find a solution anywhere so any help would be appreciated.

So after lots of investigation I finally figured out what the problem was. It was all down to redirecting from http to https. From articles I found on the web (can't remember the urls anymore), is that the libraries that the wsdl2java and wsimport stub generators use to do the webservice communication don't allow a http to https redirect follow due to security reasons.
So even though I was generating the stubs from a https wsdl location ie. https://wsdl.location.com?wsdl, when I ran the code to do a webservice call, it was trying to make the call to http://wsdl.location.com which resulted in a redirect request to https://wsdl.location.com, But the http library does not allow that. So it just forwards the 302 http code up as an exception.
Also, there are two web-service urls. One is a testing service which is normal http url and then there is a production server which is over https. So to work around this is all I did is configure the service on the fly to use the end-point I have specified (which is now the https address) by using the BindingProvider class. This also allows me to specify on the fly depending on which environment that is making to call, to use the test url or the production one ie.
NotificationWebService service = new NotificationWebService();
NotificationWebServiceSoap serviceSoap = service.getNotificationWebServiceSoap();
BindingProvider bindingProvider = (BindingProvider) serviceSoap;
bindingProvider.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://wsdl.location.com");
String xmlString = serviceSoap.getRSAPublicKeyXMLString();
So in short, if anyone encounters this problem. Make sure if the end point you need point to is on https, that you are making a direct https call and not a http call that will ask for an https redirect. You can check this by examining the serviceSoap while debugging. It will say to which url it is making the call.
I didn't look into or go with the option to configure wsdl2java and wsimport to generate the stubs and force the stubs to use the https call so that I could configure multiple url end-points for different environments.

Yes. You didn't say what you're using for the transport, but if it's something like HttpClient you need to set it up to follow redirects. You may need to fiddle with the auto-generated code, or alternatively, perhaps try a higher level abstraction, like Spring Web Services or CXF.

Reason is the redirection issue on web service call control gets transfered from HTTP to HTTPS. Edit your WSDL file you will find the below code:
original code:
soap:address location="http://www.google.com/Services/Services_xyz.asmx"
changed code:
soap:address location="https://www.google.com/Services/Services_xyz.asmx"
Just change the location attribute HTTP to HTTPS and generate the new stub using the changed WSDL file location.

Web Service client - Service definition selected is invalid

i am building a web service on eclipse using Apache AXIS 2 Webservice runtime using Apache Tomcat server (apache-tomcat-7.0.23) while running it on tomcat server it sucessfully shows that the web service is running...
But while creating Webservice client to test the web service and using the wsdl url in the server definition (http://localhost:9090/Axis2WSTest/services/Converter?wsdl), this gives below mentioned error and not letting me to create Webservice client:
The service definition selected is invalid
Can you please suggest me the error and possible solution for it?

The problem could be that your wsdl needs http authentication. I was getting the same error in eclipse, but it was because the server I was connecting to needed authentication and was returning a 401 error, so eclipse was saying it wasn't a wsdl. Eclipse doesn't seem to have the functionality to prompt for authentication, I was able to generate a client in netbeans using the same wsdl url because netbeans knows to ask for authentication.
Generate client from http authenticated wsdl

I was searching for the whole day for an answer for this,generally localhost will be added in your bypass proxy list and hence you will not encounter an error.
Go to windows--> preference-->general--> network-connection and see whether localhost is listed in your proxybypass list.If you are trying to access a external wsdl link and you under
some corporate network having proxy firewall you have to set http proxy/https proxy.

Is this how you are trying to generate client stub ?? If yes, just simply create a java project in eclipse, click on it, then press Ctrl+N, select web service client and enter your wsdl url. (make sure you have made sure you can access the wsdl url, by simply giving it in a browser).

Try replacing localhost with the actual IP address. I was facing the same problem and it worked for me this way

I had exactly same situation. For me the following worked:
I got the lead from rdp's response - "Try replacing localhost with the actual IP address. I was facing the same problem and it worked for me this way"
Using IP didn't work for me. What worked for me:
Instead of - http://servername/SomeWebService/Service.asmx?WSDL
putting FQDN for servername. For example -
http://servername.my.company.com/SomeWebService/Service.asmx?WSDL

I had the same issue and I was able to generate the stubs using soapUI. Please follow the this post. Which contains GENERATING CLIENT JAVA CODE FOR WSDL USING SOAP UI – AXIS2 WSDL2JAVA. Before that please download apache axis2 binary from here and extract it.

How do I generate a Webservice Client in IntelliJ IDEA?

I have to set up a connection to a webservice that I don't own, all I have is a link to the WSDL file. The webservice has only one method, and I need access to it. I'm trying to use the standard "Generate Java Code from Wsdl or Wadl" (or create New->Web Service Client, which ends up in the same spot)
When I enter the URL I have, the status line says "Wsdl url connection exception". If I put the url in a browser, it nicely displays the xml file, so the URL works. I have a similar problem trying to generate the code in eclipse, where it also refuses to acknowledge the URL.
It's the first time I do anything webservice related and it's driving me mad, how do I fix this?

Consuming a WCF service in a Java Client using wsHttpBinding

I'm trying to get a Java Client to communicate with a WCF wshttpbinding WebService. But I've been unsucesful so far. The call either hangs, or I get: “SOAPFaultException: The message could not be processed. This is most likely because the action 'http://tempuri.org/ISampleService/GetServiceName' is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch between bindings. The security context token would be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint's binding.”
My Web Service is just the default Visual Studio 2010 generated "WCF Service Library Template".
My java client is generated in netBeans 7.0.1 and stubs have been generated using new Other --> Web Services --> Web Service Client and I’m referencing a local WSDL.
I've tried adding WebServiceFeature wsAddressing = new AddressingFeature(true); in the stub generated but it just throws the exception above.
I see other people with similar problems; however, I don't see any true resolution. Any suggestions would be greatly appreciated.

It sounds like you have a soap formatting issue. The java client isn't generating soap XML that makes sense to the WCF service. To get an idea of what the soap XML the service is expecting use the WcfTestClient command line app to call the service. This app dynamically creates a service proxy in a WinForm app. In the app, call the service operation and click the XML tab (next to the Formatted tab at the bottom of the right pane). You'll see both the request & response soap in this tab.
Next, configure the WCF service for message tracing and call it from the java client to see the soap XML it is being sent. Now you can compare the two soap messages to see what is different. The java client will need be configured to generate the soap format the WCF is expecting.
The WCF team recently released some WCF interop bindings specifically for java. These may not apply to your specific situation but they're probably worth reviewing.