Ahah!
I didn't notice the refs in the request schema; but now that you point them
out; I know what's causing them:
My method declaration for that method on the SEI is as follows:
@ServiceOperation(type=ServiceOperationType.QUERY)
@WebMethod(operationName="getCarrier")
@RequestWrapper(className="getCarrierRequest",
targetNamespace="urn:ws.thinkingphones.com:didmanager:request")
@ResponseWrapper(className="getCarrierResponse",
targetNamespace="urn:ws.thinkingphones.com:didmanager:response")
public WSCarrier getCarrier(
@WebParam(name="username",
targetNamespace="urn:ws.thinkingphones.com:didmanager")
String username,
@WebParam(name="carrierID",
targetNamespace="urn:ws.thinkingphones.com:didmanager")
Long carrierID
);
Note how the actual WebParams are in a different namespace compared to the
RequestWrapper.
If I change the signature to:
@ServiceOperation(type=ServiceOperationType.QUERY)
@WebMethod(operationName="getCarrier")
@RequestWrapper(className="getCarrierRequest",
targetNamespace="urn:ws.thinkingphones.com:didmanager:request")
@ResponseWrapper(className="getCarrierResponse",
targetNamespace="urn:ws.thinkingphones.com:didmanager:response")
public WSCarrier getCarrier(
@WebParam(name="username",
targetNamespace="urn:ws.thinkingphones.com:didmanager:request")
String username,
@WebParam(name="carrierID",
targetNamespace="urn:ws.thinkingphones.com:didmanager:request")
Long carrierID
);
the problem disappears and java2ws no longer generates the ref (since both
the parameter and the requestWrapper are now in the same schema).
If - as you explained - a different version of jaxb is used under the hood
between java2ws and at runtime; I guess it's possible JAXB would treat that
scenario differently....
Thanks Daniel, I would never have spotted that.
--
View this message in context:
http://cxf.547215.n5.nabble.com/Unwrapped-client-problem-tp4919103p4919489.html
Sent from the cxf-user mailing list archive at Nabble.com.
