Skip to main content

JAX-WS client issue: SOAP-response result null?

6 replies [Last post]
Anonymous

Folks;

maybe a strange issue, but yet not so far sure where to look to get it
addressed. Situation: Building a SOAP client against a system we're using
here, making use of NetBeans 6.5 beta / JAX-WS 2.1. So far, here is how
things work / go:

- Creating a "Web Service Client" in the IDE works well. Using the
auto-generated stubs as well as everything else did have no problems.

- However, the SOAP call (in the auto-generated client application) failed
for obscure reasons.

Using tcpmonitor, I found the following: The request is something like this...

POST /service HTTP/1.1
SOAPAction: "login"
Accept: text/xml, multipart/related, text/html, image/gif, image/jpeg, *;
q=.2, */*; q=.2
Content-Type: text/xml;charset="utf-8"
User-Agent: JAX-WS RI 2.1.4-b01-
Host: n428:8881
Connection: keep-alive
Content-Length: 228

<?xml version="1.0" ?>krkrink

... which seems fine. The response to that, as sent by the server, also
seems fine:

HTTP/1.0 200 OK
Content-Length: 376
Content-Type: text/xml;charset=ISO-8859-1

<?xml version="1.0" encoding="ISO-8859-1"?>

1kFt9M4Nx1kQ5OU3oVb0

The is what I am after... However, using Java client code like this
to call the operation...

[...]
parameters.setUserName("kr");
parameters.setUserPassword("krink");
n428._8881.LoginResponse result = port.login(parameters);
System.out.println("result: " + result + " -- " +
result.getResult());
} catch (Exception ex) {
ex.printStackTrace();
}
[...]

... ends up like this:

[...]
run:
result: n428._8881.LoginResponse@1e46a68 -- null
[...]

... which is strange: Obviously the "result" is there in the SOAP response
but not "seen" / correctly parsed / whatever by the client code. Does anyone
have a small idea to share what's goin' on here and how to eventually get it
addressed?

Thanks in advance and best regards,
Kristian

--
Kristian Rink
cell : +49 176 2447 2771
business: http://www.planconnect.de
personal: http://pictorial.zimmer428.net
"we command the system. calling all recievers.
we are noisy people for a better living".
(covenant - "monochrome")

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Kristian Rink

Hi all;

getting back to this:
[...]
>
>
> > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>
>
> 1kFt9M4Nx1kQ5OU3oVb0
>

>

>
>
[...]
>
> parameters.setUserName("kr");
> parameters.setUserPassword("krink");
> n428._8881.LoginResponse result = port.login(parameters);
> System.out.println("result: " + result + " -- " +
> result.getResult());
> } catch (Exception ex) {
> ex.printStackTrace();
> }
> ... ends up like this:
>
> [...]
> run:
> result: n428._8881.LoginResponse@1e46a68 -- null
> [...]
>

So far I have kindly been pointed to [1] which seems reasonable but, after
talking back to our systems manufacturer, they claim that the namespace
"correction" that would be required in the response is "optional even though
recommended by SOAP 1.2" and, so, something they will not do on a short
term, partly also because they do use apache axis as Java test suite which
seems to have no problems with this. So, question on that is: Is there some
way to make JAX-WS also work with the (flawed?) XML response returned by
that system, or should I give some other tool a try? Is there something that
still can be done about it?

Thanks in advance for any comments,
Kristian

[1]http://webservices20.blogspot.com/2008/10/interoperability-gotcha.html

--
Kristian Rink
cell : +49 176 2447 2771
business: http://www.planconnect.de
personal: http://pictorial.zimmer428.net
"we command the system. calling all recievers.
we are noisy people for a better living".
(covenant - "monochrome")

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

yaronn02
Offline
Joined: 2008-03-15
Points: 0

Looking again in the request I don't think it is related to the blog post after all - if it was then the loginResponse element should have been under a namespace. So it seems this response is simply not valid without any particular excuse.

You might be able to manually alter the WSDL you use to make it think the response should be with this empty namespace but I'm not sure you will be able to.

I'm not a metro expert - maybe they will have a more straight forward idea - the only I can think of is that if this is the only operation you use and you only need the response value you can manually get a reference to this soap envelope from code and extract it. There might also be a way to create a response handler in which you may be able to "fix" this request. If you want more information on those I suggest you will open a new thread to get exposure.

Thanks,
Yaron

http://webservices20.blogspot.com/
Web Services Performance, Interoperbility And Testing Blog

Message was edited by: yaronn02

Kristian Rink

metro@javadesktop.org schrieb:
> Looking again in the request I don't think it is related to the blog post
> after all - if it was then the loginResponse element should have been
> under a namespace. So it seems this response is simply not valid without
> any particular excuse.

But unfortunately none of my validators fail on this one, neither one
obviously Apache Axis does... :/ From that point of view, there's always the
"works-with-Axis-so-must-be-fine" kind of reasoning... Asides this: How to
validate the response at all, given there's no namespace provided along with it?

> You might be able to manually alter the WSDL you use to make it think the
> response should be with this empty namespace but I'm not sure you will be
> able to.

This is not an option to me, so far; we're in the process of evaluating
buying a license for the SOAP server in this very environment, and the
requirement to work with JAX-WS has to be met before we do so. However so
far I am not sure _why_ exactly JAX-WS refuses to work with the SOAP
messages here... ;)

[...]
> use and you only need the response value you can manually get a reference
> to this soap envelope from code and extract it. There might also be a way
> to create a response handler in which you may be able to "fix" this
> request.
[...]

Also, too much work. :) As soon as I have a clue what exactly needs to be
changed about the messages to work with JAX-WS out of the box, we will talk
to our system manufacturer and see whether / how they can get the
WSDL/messages right. So far however it's trying to figure out that
particular reason... :)

Cheers & thanks,
Kristian

--
Kristian Rink * http://zimmer428.net * http://flickr.com/photos/z428/ jab:
kawazu@jabber.ccc.de * icq: 48874445 * fon: ++49 176 2447 2771 "One dreaming
alone, it will be only a dream; many dreaming together is the beginning of a
new reality." (Hundertwasser)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

yaronn02
Offline
Joined: 2008-03-15
Points: 0

> Asides this: How to validate the response at all, given there's no namespace > provided along with it?

I don't think an xml document can be valid according to a schema if it uses the default (empty) namespace. That is since you should not be able to define a schema with this target namespace. It can obviously be a problem in the future if the soap will need to contain elements from external 3rd party schemas.

http://webservices20.blogspot.com/
Web Services Performance, Interoperbility And Testing Blog

yaronn02
Offline
Joined: 2008-03-15
Points: 0

You may be experiencing an interoperability gotcha

Thanks,
Yaron

http://webservices20.blogspot.com/
Web Services Performance, Interoperbility And Testing Blog

Kristian Rink

Yaron;

metro@javadesktop.org schrieb:
> You may be experiencing an > href="http://webservices20.blogspot.com/2008/10/interoperability-gotcha.html">interoperability
> gotcha

Thanks for your pointer on that... looking at the requests / responses /
WSDL involved here, indeed it seems comparable so I will talk to our system
integrator and see whether the WSDL could be fixed up here...

Thanks so far and best regards,
Kristian

--
Kristian Rink
cell : +49 176 2447 2771
business: http://www.planconnect.de
personal: http://pictorial.zimmer428.net
"we command the system. calling all recievers.
we are noisy people for a better living".
(covenant - "monochrome")

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net