cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Clegg <and...@nervechannel.com>
Subject Re: Sending XML payload without encoding it
Date Thu, 12 Mar 2009 08:10:19 GMT
 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 <dkulp@apache.org> 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 <andrew@nervechannel.com>:
>>> 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 <xbranko@netscape.net>:
>>>> 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
> dkulp@apache.org
> http://www.dankulp.com/blog

Mime
View raw message