Skip to main content

Problems with binding, wsgen, and wsimport

4 replies [Last post]
phil_martin
Offline
Joined: 2010-06-29

Hey all. I'm new to the Java programming game, but have some experience with web services in the .Net world.

I am using Eclipse 3.5, Java SE 1.6, and JAX-WS (not certain how to figure out what specfic version), and I am having an odd mix of success and failure. Here's what I'm seeing:

I have a class annotated with @WebService, which has several methods annotated with @WebMethod. Actually, all methods are annotated this way, the ones I don't want exposed on the WS are annotated @WebService(exclude=true).

If I do not include the @BindingType attribute, then:

1.1. Good: SOAP 1.1 binding is used by default, and my Java test client can call the methods with no problems.

1.2. Bad: When a .Net project adds a web reference via the URL of the running service, I get an exception on my server. It says "com.sun.xml.internal.ws.transport.http.HttpAdapter$HttpToolkit handle
SEVERE: Unsupported Content-Type: application/soap+xml; charset=utf-8 Supported ones are: [text/xml]
com.sun.xml.internal.ws.server.UnsupportedMediaException: Unsupported Content-Type: application/soap+xml; charset=utf-8 Supported ones are: [text/xml]". As I understand it, this is because .Net tries to use SOAP1.2.

1.3. Good: When I run wsimport to generate proxy/stub classes for my Java test client, classes for the service and the port are both created as I expect, along with the classes for my methods and their responses.

1.4. Good: I am able to run wsgen without specifying the -wsdl option, and classes for my methods & their responses are generated.

1.5. Bad: If I do specify the -wsdl option (along with -r and -servicename), I get the following error:
Exception in thread "main" java.lang.NoClassDefFoundError: com/streambase/sb/StreamBaseException
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.privateGetPublicMethods(Class.java:2547)
at java.lang.Class.getMethods(Class.java:1410)
... etc.

Note that if I specify an incorrect class name or classpath, I get a different error:
Class not found: "com.rbccm.cts.sbadapter.CtsPostedNewsNotification_BAD"

1.6. Good: When I point a browser at the http://...?WSDL URI, I can see the generated WSDL and it looks superficially right.

1.4&1.5 are especially troubling to me - in case 1.4 it's able to resolve the class fine and extract the necessary information, in case 1.5 it's clearly finding the class but not able to extract the necessary information. Shouldn't it be going through the same discovery mechanism either way?

Anyhow, there's a new wrinkle if I change the binding to SOAP1.2 via the attribute @BindingType(value="http://java.sun.com/xml/ns/jaxws/2003/05/soap/bindings/HTTP/"). That value comes from Sun's own documentation, which specifies that it's non-standard but is needed for WSDL generation, which is borne out by what I see when I use the standard value (described below).

2.1. Good: SOAP 1.2 binding is used, and my Java test client can call the methods with no problems (if I use the stubs generated in 1.3 above).

2.2. Good: When a .Net project adds a web reference via the URL of the running service, I don't see any exceptions on my server, and the .Net client is able to call my methods with no problems.

2.3. Bad: When I run wsimport to generate proxy/stub classes for my Java test client, classes for the service and the port are NOT created, but the classes for my methods and their responses are.

2.4. Good: I am able to run wsgen without specifying the -wsdl option, and classes for my methods & their responses are generated.

2.5. Bad: If I do specify the -wsdl option (along with -r and -servicename), I get the same error as noted above.

2.6. Good: I can still see valid-looking WSDL at the http://...?WSDL URI.

2.7. Bad?: When I run the service, I get the following warning: com.sun.xml.internal.ws.server.EndpointFactory generateWSDL
WARNING: Generating non-standard WSDL for the specified binding

Lastly, if I use the standard value for SOAP1.2 - @BindingType(SOAPBinding.SOAP12HTTP_BINDING), I see the following:

3.1. Bad: I assume I'm using SOAP 1.2, but I'm not sure. What I am sure of is that I can no longer call the service from my Java client. It fails with the error "Failed to access the WSDL at: http://7xsq943w:8080/CTS?WSDL. It failed with:
Connection refused: connect." This is consistent with 3.6 & 3.7 below.

3.2. Neutral: I don't know if this is callable from .Net, I haven't tried it, but I have my doubts given the above.

3.3. Bad: wsimport fails when pointing at the service URI. I wanted to try using .WSDL/.XSD files generated by wsgen, but see 3.5 below.

3.4. Good: wsgen works as in 1.4 and 2.4.

3.5. Confusing: I swear that specifying the -wsdl option (along with -r and -servicename) actually worked once, and .WSDL and .XSD files were created. However, when I try again now, wsgen gives me the error "wsgen can not generate WSDL for SOAP 1.2 binding: http://www.w3.org/2003/05/soap/bindings/HTTP/ on class: com.rbccm.cts.sbadapter.CtsPostedNewsNotification."

3.6. Bad: the http://...?WSDL URI comes back as "Cannot find server" when I point a browser at it.

3.7. Bad: When I run the service, I get the following error: com.sun.xml.internal.ws.server.ServerRtException: Cannot generate WSDL for binding "http://www.w3.org/2003/05/soap/bindings/HTTP/"

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
phil_martin
Offline
Joined: 2010-06-29

Well, I got something put together that's working for my purposes, so I'll share it for posterity in the hopes that it helps someone else dealing with the same issues.

The key to getting the export & import working correctly was as follows:

1. Use the non-standard SOAP1.2 over HTTP binding.

2. Include the following arguments when involking wsgen: -extension -wsdl:Xsoap1.2

3. Include the argument -extension when invoking wsimport, and pass the name (and path) of the .WSDL file generated in step #2 above instead of the URI of the running service.

Maybe there's a better way - if someone wants to share it, that would be great.

Thanks.

phil_martin
Offline
Joined: 2010-06-29

I have found a workaround for generating the .WSDL and .XSD files. As the error shows, the problem was with finding a type (StreamBaseException) that exists in an external JAR. I was able to just remove the dependency.

I hunted around a bit and did find others trying to solve the same problem (classes in external JARs) but wasn't able to find a solution. I guess you can always remove these dependencies by changing the division of labor between the WS implementation class and another class that contains or otherwise references it.

phil_martin
Offline
Joined: 2010-06-29

Whoops, the "community news" forum is probably the wrong place for this. My bad.

phil_martin
Offline
Joined: 2010-06-29

Any help figuring out how to get this all working would be much appreciated. Here are some general questions:

1. Is there some logic behind the fact that the standard SOAP1.2 over HTML binding doesn't produce WSDL? If you use that binding, is there supposed to be another mechanism to come up with the WSDL?

2. If I can get .WSDL and .XSD files generated from the command-line using wsgen, can I somehow use those files to generate the stubs using wsimport (or another similar tool) so I can generate the stubs without the server actually running?

3. If I can't get the .WSDL and .XSD files generated using wsgen, can I just point to the relevant URI's in the browser to retreive them and save from there? I expect they should be equivalent.

Thanks very much for any advice or insight on this,
Phil Martin.