You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@cxf.apache.org by Nick Stuart <ni...@portlandwebworks.com> on 2014/10/09 16:46:11 UTC

Missing namespace prefix

Hi all, we have had some recurring issues sending messages through the CXF
client and being unable to unmarshal them correctly on the backend.

Quick environment setup: Camel 2.13.1 exposes CXF Endpoints (2.7.11) on
Glassfish 4.1 (and 4.0) running on either jdk 7 or 8.

The client sending the request is CXF 2.7.11 as well, wired up with spring.
Most of our messages work fine, however we sometimes have issues with null
pointer exceptions on the backend for some (seemingly) random messages.

Here are two sample messages. The top one does not work, the bottom one does

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns2:allUsers xmlns:ns2="http://admin.sample.com/">
<arg0>
<sortColumn>email</sortColumn>
<sortOrder>ASC</sortOrder>
<sample>
<locked>false</locked>
<companyAdmin>false</companyAdmin>
</sample>
<offset>0</offset>
<limit>25</limit>
</arg0>
</ns2:allUsers>
</soap:Body>
</soap:Envelope>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns2:list xmlns:ns2="http://users.sample.com/">
<ns2:arg0>
<sortColumn>email</sortColumn>
<sortOrder>ASC</sortOrder>
<sample>
<firstName>bri</firstName>
<locked>false</locked>
<companyAdmin>false</companyAdmin>
</sample>
<offset>0</offset>
<limit>25</limit>
</ns2:arg0>
</ns2:list>
</soap:Body>
</soap:Envelope>

Both endpoints actually share the same method parameter type on the backend
(called ListUserRequest) and everything is generated from the same set of
wsdls.

The difference with the 'broken' one is the <arg0>. It does not have the
ns2 prefix on it, and when it gets back to the backend it things the
argument is null. I thought I had found a 'fix' for this, but apparently
not.

Any insight or thoughts would be greatly appreciated.
-Nick

Re: Missing namespace prefix

Posted by Daniel Kulp <dk...@apache.org>.

Check the WSDL/schema to make sure the wsdl has elementFormDefault=“qualified” on the <schema>.  That should generate the appropriate package-info.java.   That said, you may want to add -xjc-npa to the wsdl2java call to have it NOT use the package-info and stick the namespace on all the annotations that need it.   Sometime (especially in OSGi where context-classloaders may be munged a bit), there are problems finding the package-info.

Dan


On Oct 9, 2014, at 11:37 AM, Nick Stuart <ni...@portlandwebworks.com> wrote:

> Ok, found the root of the problem, still don't know how to properly 'fix'
> it though. The generated code for the package-info.java for the request
> that doesn't work has:
> 
> @javax.xml.bind.annotation.XmlSchema(namespace = "http://admin.sample.com/")
> 
> The one that works has:
> 
> @javax.xml.bind.annotation.XmlSchema(namespace = "http://users.sample.com/",
> elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
> 
> https://java.net/jira/browse/JAXB-818 and few other mentions of things
> similar, but no description of this exact situation (most of them refer to
> customizing the prefix, I just want it to show up!)
> 
> My ugly 'fix' would be to manually create the package-info classes and to
> not generate them. Not really nice, but it will work. :(
> 
> On Thu, Oct 9, 2014 at 10:46 AM, Nick Stuart <ni...@portlandwebworks.com>
> wrote:
> 
>> Hi all, we have had some recurring issues sending messages through the CXF
>> client and being unable to unmarshal them correctly on the backend.
>> 
>> Quick environment setup: Camel 2.13.1 exposes CXF Endpoints (2.7.11) on
>> Glassfish 4.1 (and 4.0) running on either jdk 7 or 8.
>> 
>> The client sending the request is CXF 2.7.11 as well, wired up with
>> spring. Most of our messages work fine, however we sometimes have issues
>> with null pointer exceptions on the backend for some (seemingly) random
>> messages.
>> 
>> Here are two sample messages. The top one does not work, the bottom one
>> does
>> 
>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>> <soap:Body>
>> <ns2:allUsers xmlns:ns2="http://admin.sample.com/">
>> <arg0>
>> <sortColumn>email</sortColumn>
>> <sortOrder>ASC</sortOrder>
>> <sample>
>> <locked>false</locked>
>> <companyAdmin>false</companyAdmin>
>> </sample>
>> <offset>0</offset>
>> <limit>25</limit>
>> </arg0>
>> </ns2:allUsers>
>> </soap:Body>
>> </soap:Envelope>
>> 
>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>> <soap:Body>
>> <ns2:list xmlns:ns2="http://users.sample.com/">
>> <ns2:arg0>
>> <sortColumn>email</sortColumn>
>> <sortOrder>ASC</sortOrder>
>> <sample>
>> <firstName>bri</firstName>
>> <locked>false</locked>
>> <companyAdmin>false</companyAdmin>
>> </sample>
>> <offset>0</offset>
>> <limit>25</limit>
>> </ns2:arg0>
>> </ns2:list>
>> </soap:Body>
>> </soap:Envelope>
>> 
>> Both endpoints actually share the same method parameter type on the
>> backend (called ListUserRequest) and everything is generated from the same
>> set of wsdls.
>> 
>> The difference with the 'broken' one is the <arg0>. It does not have the
>> ns2 prefix on it, and when it gets back to the backend it things the
>> argument is null. I thought I had found a 'fix' for this, but apparently
>> not.
>> 
>> Any insight or thoughts would be greatly appreciated.
>> -Nick
>> 

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Re: Missing namespace prefix

Posted by Nick Stuart <ni...@portlandwebworks.com>.

Ok, found the root of the problem, still don't know how to properly 'fix'
it though. The generated code for the package-info.java for the request
that doesn't work has:

@javax.xml.bind.annotation.XmlSchema(namespace = "http://admin.sample.com/")

The one that works has:

@javax.xml.bind.annotation.XmlSchema(namespace = "http://users.sample.com/",
elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED)

https://java.net/jira/browse/JAXB-818 and few other mentions of things
similar, but no description of this exact situation (most of them refer to
customizing the prefix, I just want it to show up!)

My ugly 'fix' would be to manually create the package-info classes and to
not generate them. Not really nice, but it will work. :(

On Thu, Oct 9, 2014 at 10:46 AM, Nick Stuart <ni...@portlandwebworks.com>
wrote:

> Hi all, we have had some recurring issues sending messages through the CXF
> client and being unable to unmarshal them correctly on the backend.
>
> Quick environment setup: Camel 2.13.1 exposes CXF Endpoints (2.7.11) on
> Glassfish 4.1 (and 4.0) running on either jdk 7 or 8.
>
> The client sending the request is CXF 2.7.11 as well, wired up with
> spring. Most of our messages work fine, however we sometimes have issues
> with null pointer exceptions on the backend for some (seemingly) random
> messages.
>
> Here are two sample messages. The top one does not work, the bottom one
> does
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <ns2:allUsers xmlns:ns2="http://admin.sample.com/">
> <arg0>
> <sortColumn>email</sortColumn>
> <sortOrder>ASC</sortOrder>
> <sample>
> <locked>false</locked>
> <companyAdmin>false</companyAdmin>
> </sample>
> <offset>0</offset>
> <limit>25</limit>
> </arg0>
> </ns2:allUsers>
> </soap:Body>
> </soap:Envelope>
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <ns2:list xmlns:ns2="http://users.sample.com/">
> <ns2:arg0>
> <sortColumn>email</sortColumn>
> <sortOrder>ASC</sortOrder>
> <sample>
> <firstName>bri</firstName>
> <locked>false</locked>
> <companyAdmin>false</companyAdmin>
> </sample>
> <offset>0</offset>
> <limit>25</limit>
> </ns2:arg0>
> </ns2:list>
> </soap:Body>
> </soap:Envelope>
>
> Both endpoints actually share the same method parameter type on the
> backend (called ListUserRequest) and everything is generated from the same
> set of wsdls.
>
> The difference with the 'broken' one is the <arg0>. It does not have the
> ns2 prefix on it, and when it gets back to the backend it things the
> argument is null. I thought I had found a 'fix' for this, but apparently
> not.
>
> Any insight or thoughts would be greatly appreciated.
> -Nick
>