From my own POV this is non-urgent now - I've wrappered Dispatch in
another class that forks a second thread to change the context AND do
the invoke. Code available if anyone wants it as a workaround, but I
don't think it's patch material.
Cheers,
Andrew.
On 11 Mar 2009, at 20:41, Daniel Kulp <[email protected]> wrote:
I'm going to dump this in with:
https://issues.apache.org/jira/browse/CXF-1907
Ideally, the Dispatch would be wrappering a ClientImpl and just use
the
context support in there instead of doing it's own version of it
(and doing it
wrongly). CXF-1907 is on my current "todo" list for early April,
but
subject to change.
Dan
On Tue March 10 2009 1:31:35 pm Andrew Clegg wrote:
Branko, thanks for your help, I've got a theory about what might be
causing this.
CXF gurus -- I've noticed that the request context in
BindingProviderImpl is stored in a ThreadLocal.
I'm adding something to a DispatchImpl's request context, and then
calling its invokeAsync method, therefore it's being invoked in a
different thread.
Correct me if I'm wrong, but doesn't this mean that an asynchronously
invoked Dispatch will *never* be able to see the same request context
that it was set up with?
I tried this, extrapolating in reverse from the FAQ:
_dispatch.getRequestContext().put( "thread.local.request.context",
"false"
);
but it made no difference.
Thanks,
Andrew.
2009/3/10 Andrew Clegg <[email protected]>:
I don't get it... How does building the XML payload differently mean
you get a SOAPAction header? Or do you mean, when you do it this
way,
you don't need a SOAPAction header?
In my case, I absolutely need a SOAPAction header matching the WSDL,
because it's some weird Perl service implementation, and this:
_dispatch.getRequestContext().put(
BindingProvider.SOAPACTION_USE_PROPERTY, Boolean.TRUE );
_dispatch.getRequestContext().put(
BindingProvider.SOAPACTION_URI_PROPERTY, "the action URI" );
isn't making *any* difference at all :-(
No matter how I try to rephrase it, Wireshark just shows:
SOAPAction: ""
in the outbound request, and the remote service throws an error. I
have debugged into the code to some extent and those put() calls are
definitely taking place.
Sorry, I know your problem was a little different from mine, but I
was
really hoping you'd figured out what the right magic words were :-)
Andrew.
2009/3/10 xbranko <[email protected]>:
Andrew Clegg-2 wrote:
I just found this message from last month...
How did you get the SOAPAction header thing to work in the end?
I have
I couldn't get the action to appear either, so finally this is
what I
ended up with:
try
{
String xmlPayload = "<yourXML>...</yourXML>";
Service service = Service.create(new URL(wsdl), SERVICE_NAME);
InputStream is = new
ByteArrayInputStream(xmlPayload.getBytes());
SOAPMessage message =
MessageFactory.newInstance().createMessage(null, is);
DOMSource request = new
DOMSource(message.getSOAPBody().extractContentAsDocument());
Dispatch<DOMSource> disp = service.createDispatch(PORT_NAME,
DOMSource.class, Service.Mode.PAYLOAD);
DOMSource result = disp.invoke(request);
DOMResult domResponse = new DOMResult();
Transformer trans =
TransformerFactory.newInstance().newTransformer();
trans.transform(result, domResponse);
}
catch(Exception e)
{
e.printStackTrace();
}
Ideally, the CXF team would implement an annotation for parameter
(say
@NoEncoding) that would just pass the content as is, i.e. without
any
XML character encoding. Hey CXF team -- how about that?
--
View this message in context:
http://www.nabble.com/Sending-XML-payload-without-encoding-it-tp21925398
p22438203.html Sent from the cxf-user mailing list archive at
Nabble.com.
--
:: http://biotext.org.uk/ ::
--
Daniel Kulp
[email protected]
http://www.dankulp.com/blog
