Thanks for the very swift turnaround on this, Dan! Andrew.
2009/3/12 Daniel Kulp <[email protected]>: > On Thu March 12 2009 4:10:19 am Andrew Clegg wrote: >> 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. > > Found a simple fix anyway. When we push the call onto the background thread, > copy the context with it. That should work till the big refactor can take > place. > > Dan > >> >> 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-tp219253 >> >>>>98 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 > > -- > Daniel Kulp > [email protected] > http://www.dankulp.com/blog > -- :: http://biotext.org.uk/ ::
