Per spec, if you want the parameters to be qualified, you need to add the targetNamespace attribute onto the @WebParam (and @WebResult) annotations. By default, they will result in unqualified parameters.
However, what you MAY be seeing is if the wrapper types that CXF generates end up going into the exact same schema of the other types, and that schema has already been qualified due to JAXB package-info.java settings, it may be flip to qualified. Dan On May 13, 2013, at 6:00 AM, James Green <[email protected]> wrote: > SOAP-UI also reports this error. > > If I remove @WebParam from the method parameters the service calls no > longer error at the protocol layer. Yet we have other services elsewhere > using @WebParam with no such problems. > > > On 13 May 2013 10:23, James Green <[email protected]> wrote: > >> Service class: http://pastebin.com/tSRhWXbv >> >> Stack trace: http://pastebin.com/yBBfv6gG >> >> The content of a test. The first call works, the second call resulted in >> Unmarshalling Error: unexpected element (uri:" >> http://www.mjog.net/doc/2012-08-01";, local:"createKeyRequest"). Expected >> elements are <{}createKeyRequest> : >> CreateKeyStoreRequest request = new CreateKeyStoreRequest(); >> request.setName("test-keystore"); >> request.setPassword("test-password"); >> request.setType("JCEKS"); >> >> KeyStoreService_Service service = new KeyStoreService_Service(new >> URL(SERVICE)); >> try { >> service.getKeyStorePort().create(request); >> } catch (SOAPFaultException cause) { >> System.out.println("A soap fault happened: " + cause); >> } catch (ConflictException_Exception cause) { >> // Key store by that name already exists >> } >> >> CreateKeyRequest keyRequest1 = new CreateKeyRequest(); >> CreateKey ck = new CreateKey(); >> ck.setCreateKeyRequest(keyRequest1); >> keyRequest1.setKeyStoreName("test-keystore"); >> keyRequest1.setPassword("key-password"); >> service.getKeyStorePort().createKey(ck); >> >> >> >> On 13 May 2013 09:31, Freeman Fang <[email protected]> wrote: >> >>> Hi, >>> >>> You probably need post your SEI/Impl class here, as well as the full >>> stack trace. >>> －－－－－－－－－－－－－ >>> Freeman(Yue) Fang >>> >>> Red Hat, Inc. >>> FuseSource is now part of Red Hat >>> Web: http://fusesource.com | http://www.redhat.com/ >>> Twitter: freemanfang >>> Blog: http://freemanfang.blogspot.com >>> http://blog.sina.com.cn/u/1473905042 >>> weibo: @Freeman小屋 >>> >>> www.camelone.org : The open source integration conference: >>> >>> On 2013-5-13, at 下午4:20, James Green wrote: >>> >>>> Hi, >>>> >>>> We have written a web tier with a number of classes exposed using the >>>> @WebService annotation including a targetNamespace value e.g. >>>> >>>> @WebService(targetNamespace="http://ourco.com/doc";) >>>> class Service { >>>> } >>>> >>>> Inside these services the public methods are, as expected, exposed as >>>> methods with parameters. We can build clients using auto-generated >>> wsimport >>>> and indeed wsdl2java and use them as expected. So far so good. >>>> >>>> We recently added another couple of these classes using the above >>> recipe. >>>> This time disaster - the server (TomEE 1.6 snapshot - last week) issues >>> an >>>> exception that the parameter has a namespace - but that none was >>> expected. >>>> That's the conclusion reached from Googling the error... >>>> >>>> The parameters are just POJOs with @XmlRootElement - no namespace >>>> specified. This is the same across the app. We began playing with >>> different >>>> combinations of empty namespaces on @WebParam etc and came up with >>>> inconsistent results. >>>> >>>> In fact right now one method requires a parameter with a namespace, >>> another >>>> in the same class requires an empty namespace! >>>> >>>> I'm baffled by SOAP most of the time but this has be stumped. Any ideas >>>> what to do next? >>>> >>>> Thanks, >>>> >>>> James >>> >>> >> -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
