users@glassfish.java.net

Glassfish, JAX-WS 2.2.x and "empty" headers?

From: Kristian Rink <kr_at_zimmer428.net>
Date: Tue, 27 Mar 2012 16:13:09 +0200

[crossposting as though this actually should go to the jaxws mailing
list which seems not to work for me right now - hope that's ok with you]


Folks;

I am dealing with a peculiar problem regarding SOAP messages and
headers: One of the services we're supposed to work with makes use of
headers for keeping track of users being in a valid session, and this
header just needs to be around as soon as a user has been logged in,
i.o.w. there is a "get session id" method which does not expect this
header to be around. If the header is present yet empty, the server will
fail with an error message.

I have tried the same using Apache CXF, including generating stubs from
the WSDL provided by the service, and it works fine there. Two sample
messages:

- This is the "good" message, i.o.w. the one that works, generated from
stubs using Apache CXF:

<?xml version='1.0' encoding='UTF-8'?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
  <getSessionIDParamsIN xmlns="http:/name.space">

  </getSessionIDParamsIN>
</soap:Body>
/soap:Envelope>



- This is the "bad" message that doesn't work, sent using a recent Metro
implementation (Glassfish v3.1.1):

<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
  <S:Header>
   <SessionHeader xmlns="http:/name.space"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
  </S:Header>
  <S:Body>
   <getSessionIDParamsIN xmlns="http:/name.space">
  [...]
   </getSessionIDParamsIN>
</S:Body>
</S:Envelope>



I spent quite some time fiddling with both frameworks, but in the end it
really comes down to JAX-WS sending the 'nil="true"' session header
structure which CXF doesn't; if I remove the whole <S:Header> thing from
the Metro message and send this via SOAPUI, it works, too.

What makes me wonder is that, in both cases, the WSDL the stubs have
been generated from is all the same, so I wonder what I can do to make
Metro behave the same way CXF does, here? Though at the moment I could
eventually relax as, having it working with CXF, at the very least it
works, but given it runs in a Glassfish and Metro is already there, I'd
definitely prefer using the Metro implementation rather than having to
add yet another dependency.

Thoughts? Comments? Any input on that greatly appreciated. :)
TIA,
Kristian