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 <n...@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 <n...@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 dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
