I suspect that it is a XML namespace issue. Take a look at the body of the SOAP response message:
There is one namespace used for the <getPegasusVersionInfoResponse> element and another one, the empty, used with the <getPegasusVersionInfoReturn> element.
I suspect JAXB is having problems processing the result and, due to the above mentioned namespace prefix issues, fails to recognize the elements containing the response data.
My advice is to take a response message and write a small program that creates an object hierarchy from the response using JAXB and the classes generated by NetBeans. Then manipulate the response until it is accepted. Having arrived at a result, you can devise some plan to correct incoming responses, perhaps using a client-side handler.
Thank you, it seems to be a good idea. But how can I get to response message? I haven't direct access to it, because
so i work with objects, not directly with messages. Messages are generated from stub:
and here is the GetPegasusVersionInfoResponse class:
posted 9 years ago
You can try one of the following:
- Write a handler that logs outgoing (and optionally incoming) SOAP messages from/to the client.
For a complete description, follow the link in my signature and download the SCDJWS Study Notes and read section 9.5.
- Use the Membrane SOAP monitor software: http://www.membrane-soa.org/ This software can act as a proxy through which SOAP messages are sent. It keeps track of the messages passing through and lets you examine them.
You will have to override the endpoint address in the WSDL, as described here: http://metro.java.net/guide/How_to_invoke_and_endpoint_by_overriding_endpoint_address_in_the_WSDL.html
Finally, if you wish to experiment with modifications to response messages, you can use the mock web service feature in soapUI to feed the client with hand-crafted SOAP responses.
thank you for your help and study materials.
I wrote a handler that logs outgoing/incoming messages to/from TecDoc. Now it's clear, that communication is all right. Outgoing SOAP messages are generated corectly (from stub request object) because after sending I get the SOAP response message. So the problem is realy the creating response object from SOAP message. I know it could be solved by writing my own
client stub code that would process incoming SOAP messages and create every response object "by hand", as you advised me. But first, I would like to try correct the stub (generated by Netbeans) using JAXB.
So if anyone have any idea, what could be wrong in the annotatinons, which are used in the getPegasusVersionInfo() and getPegasusVersionInfoResponse(), please write it
The source code with annotations is mentioned in my previous message.
Thanks and regards,
posted 9 years ago
Please correct me if I am wrong, but as far as I have understood you have only developed the client to the web service and not the web service itself?
If the web service accepts your request messages and return a response which your client cannot interpret and the client is automatically generated using wsimport or similar tool, then I'd say the problem is with the service - the generated response messages may have some problem.
I notice that the web service was built with Axis 1.2 almost 6 years ago. I suspect this will not exactly contribute to interoperability with JAX-WS.
you are right, I have to develope the client only. So i don't have any possibility how to affect the web service itself. I have only its documentation TecDoc web service
Netbeans uses Metro 2.0 project (wsimport tool) for stub generating. So do you thing i have no chance with JAX-WS?
posted 9 years ago
An attempt with JAX-WS:
A request from a client generated in NetBeans 6.9 looks like this:
The response received from the web service looks like this:
According to the above, the <getPegasusVersionInfoReturn> element belongs to the "" XML namespace.
If we then look at the VersionInfoResponse class generated by JAXB, we can see this:
Notice that the namespace is http://datatype.cat.tecdoc.net.
I wrote a small program that used JAXB to unmarshal XML into a response object. If I tried to unmarshal the original response above, the only thing I were able to obtain was null.
After some modifications to the response, I finally managed to unmarshal it correctly. The modified response looks like this:
As I suspected, there is something wrong with the responses generated by the web service.
It is possible to develop a client that is able to talk to this web service, but you may have to write a handler that transforms incoming responses to a format that can be unmarshalled by the generate JAXB classes.
Alternatively you can write a client that uses some other way to parse the incoming responses, for instance StAX, DOM etc etc.
Personally, I think the first alternative is the cleanest, less work-intensive one.