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
