dev@jax-ws.java.net

Re: Namespace of webparam objects (wsimport generated stubs problem)

From: Cornils, Malte <Malte.Cornils_at_charite.de>
Date: Tue, 28 Jun 2011 13:39:49 +0200

Hello,

as far as I know, I'm not using rpc-literal style. The generated WSDL (e.g. at:
http://t-tmcc-tfe01.charite.de/WS_Controller_UnifiedReceive/UnifiedReceiveService?wsdl)
shows

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

as its only binding entry.

I have not specified any @SOAPBinding, so it should default to document/literal (and it seems
that it indeed does). I've also seen this restriction in one of your issue comments and checked
that before my initial posts, but unfortunately forgot to mention it.

thanks for the super-fast reply,
-Malte Cornils

________________________________
From: Rama Pulavarthi [mailto:rama.pulavarthi_at_oracle.com]
Sent: Tuesday, June 28, 2011 3:30 AM
To: dev_at_jax-ws.java.net
Cc: Cornils, Malte
Subject: Re: Namespace of webparam objects (wsimport generated stubs problem)

Hi,
Are you using rpc-literal style?

As per Basic Profile [1], 4.7.14 Part Accessors

For rpc-literal envelopes, WSDL 1.1 is not clear what namespace, if any, the accessor elements for parameters and return value are a part of. Different implementations make different choices, leading to interoperability problems.
R2735 An ENVELOPE described with an rpc-literal binding MUST place the part accessor elements for parameters and return value in no namespace.

thanks,
Rama Pulavarthi

[1] http://ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html#R2735




On 06/27/2011 06:01 AM, malte.cornils_at_charite.de<mailto:malte.cornils_at_charite.de> wrote:

Hello,



I'm facing a problem somewhat similar to JIRA issue 842

(http://java.net/jira/browse/JAX_WS-842), which already had

some helpful comments by Rama Pulavarthi leading my a little further.



We have an object (with fields containing references to other objects,

e.g. KeyValue)

called Event that has been given namespace annotations like this:



@XmlRootElement(namespace = "http://tmcc.charite.de"<http://tmcc.charite.de>)

@XmlType(namespace="http://tmcc.charite.de"<http://tmcc.charite.de>)

public class Event ... {



       @XmlElement(namespace = "http://tmcc.charite.de"<http://tmcc.charite.de>)

       public KeyValue[] getKeyvalue() {...



In our web service, we have a method called "listen" that takes one of

these as

a Webparam. We explicitly specify the namespace there:



@WebMethod(operationName = "listen")

       @WebResult(name = "event", targetNamespace =

"http://tmcc.charite.de"<http://tmcc.charite.de>)

       public Event listen(

                     @WebParam(name = "event", targetNamespace =

"http://tmcc.charite.de"<http://tmcc.charite.de>) Event event, ...



This (dual) specification of namespaces works e.g. for SoapUI, which

generates wire

soap messages containing this:



     <tmcc:listen>

       <tmcc:event>

          <tmcc:keyvalue> <!-- one of the sub-elements -->

          </tmcc:keyvalue>

       </tmcc:event>

     </tmcc:listen>



However, when using wsimport to generate stub code and calling the

listen method,

on the wire, the following is sent:



<ns2:listen xmlns:ns2="http://tmcc.charite.de"<http://tmcc.charite.de>

xmlns:ns3="http://de.tembit.com/zpsd"<http://de.tembit.com/zpsd>>

<event>

<ns2:keyvalue>



which is not accepted by the web service (probably since event is not

qualified).



When using package-info.java in the code containing the client to set

the elements

to qualified like this:



@XmlSchema( namespace = "http://tmcc.charite.de"<http://tmcc.charite.de>, elementFormDefault =

XmlNsForm.QUALIFIED )

package de.charite.tmcc.stubs;

import javax.xml.bind.annotation.XmlSchema;



I get the following over the wire:

<listen xmlns="http://tmcc.charite.de"<http://tmcc.charite.de>

xmlns:ns2="http://de.tembit.com/zpsd"<http://de.tembit.com/zpsd>>

<event>

<keyvalue>



That means the namespace prefixes are dropped from all the internal

elements.

However, since the default NS has been set and is thus also valid for

the

children elements, everything is fine. This is accepted by the stub

(Yay!).



However, unfortunately, we need the namespace prefixes to be there like

in the

SoapUI request.



Is there any way to force the JAX-WS generated client to prefix-qualify

all

the elements, especially the <event> element?



If it helps, I can send over a zipped eclipse project. Is there any

documentation

I have missed? The link to the architecture document and to the web

forums

seems to be dead, as well as some links in the wiki.



Do you have any idea where I can find documentation regarding this

behaviour, or better yet, example code how to get the JAX-WS client

to behave like SoapUI in this case?



Any help would be greatly appreciated; I'm also willing to write up

my experiences more fully and post them online so others won't

have the same problem.



Yours,

-Malte Cornils