We Keep Coding

Jax-WS: message validation

I communicate with a SOAP-service that throws that exception because of my message.
com.sun.xml.wss.XWSSecurityException: java.lang.ClassCastException: com.sun.xml.messaging.saaj.soap.impl.SOAPTextImpl cannot be cast to javax.xml.soap.SOAPElement
I think it is Java JAX-WS and the problem is somewhere in the XML of the SOAP.
Now I think of building also a simple service that gives me the chance to parse my own message.
Is there a fast an simple way with JAX-WS to parse a string that represents a SOAP-message?
Or do I need to build it full up (WSDL, ...).
Or is there maybe a SOAP-validator that uses JAX-WS?
I just have the problem with this one service. I communiacate with a bunch of others that are fine with my message. So I think it is specific to Java and implementation.
Thanks for help.
Chris

Error creating webservice client

I am trying to create a new Web Service client through STS IDE using the wsdl URL. I get error "WSDL file has validation errors. Code generation may fail." during wsdl validation phase.
Message: A problem occured while running WS-I WSDL conformance check:
org.eclipse.wst.wsi.internal.analyzser.WSIAnalyzerException:
The WS-I Test Assertion Document (TAD) document was either
not found or could not be processed.
The WSDLAnalyzer was unable to validate the given WSDL file.
Is there a problem in the service itself or am i making any mistake in creating the client ? Any help is appreciated.

Using CXF With an WSDL that has unpublished metadata

I'm using CXF to to communicate with a WSDL made in WCF. The WCF side of things was created following a tutorial. The Java code has been generated using a Maven script.
I have gotten things working using HTTPS for encryption. I have gotten authentication working. However, I would like to have the WSDL metadata turned off on the WCF side and still be able to use the Java side to talk to the service.
Currently, I can access the service with metadata publishing on from the Java side using this code:
URL wsdlLocation = new URL("https://server.com:7010/Hservice?wsdl");
HttpsURLConnection connection = (HttpsURLConnection) wsdlLocation.openConnection();
HService service = new HService(wsdlLocation);
HAdminService calc = service.getHAdminService();
... (authentication using WSS4JOutInterceptor code and unrelated code here)
System.out.println(calc.add(new Double(5), new Double(5)));
However, when I turn off metadata publishing on the WCF side I get this error:
Exception in thread "main" javax.xml.ws.WebServiceException:
org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service.
at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:149)
at org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:90)
at javax.xml.ws.Service.<init>(Service.java:56)
at com.blah.hservice.v_1_0.HService.<init>(HService.java:49)
at Main.main(Main.java:85)`
The page the wsdl is on displays this with metadata publishing turned off (this is an excerpt):
This is a Windows© Communication Foundation service.
Metadata publishing for this service is currently disabled.
If you have access to the service, you can enable metadata publishing by completing the following steps to modify your web or application configuration file:
I expected to be able to search "CXF metadata unpublished" and see lots of people doing this...but have not found anything. How do I communicate with this service without the WSDL being published?

You really have two options:
Copy the wsdl locally and point the client at the local wsdl. This is likely the "best" option as it makes sure all the information in the wsdl (like policies and such) is used.
Use "null" for the wsdl location (note: not JAX-WS portable). You will need to call service.addPort(....) after creating the service and before calling getHAdminService to add the port with the appropriate binding and endpoint address. CXF can work most of the time without the WSDL (will internally generate what is needed from the annotations). However, if things like policies are defined in the WSDL, then it cannot.

I got this to work with Client code I generated using CXF 2.6.5
Make sure the QName(first argument) matches the QName the getHAdminService() method references. The bindingId(second argument) should be one of the constants defined in SOAPBinding Interface (javax.xml.ws.soap.SOAPBinding).

Need help deciphering a small stack trace: which kind of WS am I using?

I'm trying to deploy an application and I've got a webservice that is unavailable. By contacting the team responsible for the webservice, they're asking me if I'm using Axis or SpringWS to access their webservice (apparently in my case there's no other option). Can this be determined from the following (partial) stack trace ?
Here's the Tomcat log I got:
INFO main # jaxws.PlatosJaxWsPortProxyFactoryBean - Retrieve of the wsdl informations.
Retrieving document at 'http://www.xxxxxxxxxxxxxxxx?wsdl'.
ERROR main # utilities.WSDLAnalyzer - javax.wsdl.WSDLException: WSDLException: faultCode=OTHER_ERROR: Unable to resolve imported document at 'http://www.xxxxxxxxxxxx?wsdl'.: java.io.IOException: Server returned HTTP response code: 503 for URL: http://www.xxxxxxxxxx?wsdl

Neither, judging by the info you posted you are using GlassFish Metro.

You're using some implementation of the JAX-WS API, but the error doesn't indicate which one.
Most likely it's the JAX-WS implementation that ships internally to Java6, but it could also be something like Apache CXF or Metro. What's on your application's classpath?

Are these two the only options?
Google says it might be something called Petals Service Engine.

You should contact the ISMS-ALSA department of your company. And, by the way, you're not supposed to use Axis, nor Glassfish Metro!
p.s.: the best answer should rather be assigned to skaffman.

RPC/Encoded Jboss problem

I'm running jboss-4.2.1.GA to generate WS requests.
I have created the WS client with the help of JWSDP-2.0/JAXRPC. I have deployed the client to Jboss and I am now trying to send requests.
When I try to initialise the client service: javax.xml.rpc.Service service = servicefactory.createService(new URL(wsdlURL), serviceQN), Jboss starts to complain.
The error that Jboss generates is:
ERROR [JBossXSErrorHandler]
JBossWS_targetnamespace1.com7796329154971783225.xsd[domain:http://www.w3.org/TR/xml-schema-1]::[key=src-resolve.4.2]::Message=src-resolve.4.2:
Error resolving component
'tns2:SimpleSerialiser'. It was
detected that 'tns2:SimpleSerialiser'
is in namespace
'http://targetnamespace2.com', but
components from this namespace are not
referenceable from schema document
'file:/home/jbossPath/jboss-4.2.1.GA/server/default/tmp/jbossws/JBossWS_targetnamespace1.com7796329154971783225.xsd'.
If this is the incorrect namespace,
perhaps the prefix of
'tns2:SimpleSerialiser' needs to be
changed. If this is the correct
namespace, then an appropriate
'import' tag should be added to
'file:/home/jbossPath/mobaq/jboss-4.2.1.GA/server/default/tmp/jbossws/JBossWS_targetnamespace1.com7796329154971783225.xsd'.
Followed by a warning:
WARN [WSDL11Reader] Encoding style
'http://schemas.xmlsoap.org/soap/encoding/'
not supported for:
{urn:namespace}doTask
Finally, the following error is displayed:
ERROR [STDERR]
org.jboss.ws.WSException: Cannot
obtain java type mapping for:
{urn:namespace}ArrayOf_tns2_TagType
ERROR [STDERR] at
org.jboss.ws.metadata.builder.jaxrpc.JAXRPCMetaDataBuilder.buildInputParameter(JAXRPCMetaDataBuilder.java:266)
...
...
I know that a similar error has been posted in community.jboss.org in the past but for a different task. I am not sure if the patch provided will solve my issue and I don't know how to implement the patch provided.
In addition to this, I have found someone having similar issues: JAX-RPC in JBoss 4.2.3 but the suggested solution does not work for me.
I also know that JbossWS does not support RPC/Encoded but I use jboss for my solution.
Is there a way for me to get around this issue, can I not get Jboss to create the client service to send requests? I'm not sure requesting a RPC/Literal WSDL file is a possibility so that's why I am asking.
Any suggestions will be greatly appreciated.

http://schemas.xmlsoap.org/soap/encoding/ is a legacy style used by very old web service stacks (it's so bad, even Microsoft recommend against it). It was seriously flawed, and so was excluded from the WS-I interoperability spec, which most modern Java web service stacks implement.
The only java stack that I know of that handles these old encoding is Axis 1, which is itself seriously flawed, but may be your only option. You should be able to run Axis as a client from inside JBoss.

I finally solved the issue by implementing the solution suggested from JAX-RPC in JBoss 4.2.3 post:
To jump to the chase, I simply put the following JARs from Axis 1.4 in my EAR's lib directory:
axis.jar, axit-ant.jar, commons-discovery-0.2.jar, jaxrpc.jar, saaj.jar, wsdl4j-1.5.1.jar
What I was doing was putting the above jars with my own WS Client jar file and that's why it didn't work. The solution was there, in front of me in black and white and I didn't implement it properly. That's the problem when looking too closely to an issue for too long.
I am a numpty.