You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by xbranko <xb...@netscape.net> on 2009/02/10 01:41:20 UTC
Sending XML payload without encoding it
Tried with both CXF 2.0.9 and 2.1.3:
I need to send payload that is XML. When I do, the content is encoded (i.e.
all '<' are replaced with <, '>' with > etc.), and the server throws
an exception because it doesn't expect payload to be encoded. I verified
that using soapui which sends the pure XML and receives correct answer from
the server.
Searching through the forum, I've implemented the alternative approach:
Service service = Service.create(new URL(wsdl), SERVICE_NAME);
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setNamespaceAware(true);
DocumentBuilder builder = factory.newDocumentBuilder();
InputStream is = new StringBufferInputStream(xmlPayload);
Document newDoc = builder.parse(is);
DOMSource request = new DOMSource(newDoc);
Dispatch<Source> disp = service.createDispatch(PORT_NAME,
Source.class, Service.Mode.PAYLOAD);
disp.getRequestContext().put(BindingProvider.SOAPACTION_USE_PROPERTY,
Boolean.TRUE);
disp.getRequestContext().put(BindingProvider.SOAPACTION_URI_PROPERTY,
"ServiceX");
Source result = disp.invoke(request);
With this approach, the server is returning:
"Unable to handle request without a valid action parameter. Please supply a
valid soap action."
I followed the code in the debugger, and saw that action parameter is being
set in the code, however, it does not get written out as part of the POST
request -- verified via the Network Protocol Analyzer -- the action is not
there.
Is there a third way? Ideally, I'd like to use the standard way, and just
indicate to CXF to do nothing with the payload, to just pass it through as
is.
Any help greatly appreciated!
--
View this message in context: http://www.nabble.com/Sending-XML-payload-without-encoding-it-tp21925398p21925398.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: Sending XML payload without encoding it
Posted by xbranko <xb...@netscape.net>.
Hi Seán,
With the example's help I was able to get it done. It took a while. Thanks
for pointing me there.
How about adding a feature that would not require one to use this
exceedingly complex process? Could this not be achieved by adding a
parameter annotation (e.g. @NoEncoding, or some such)?
Alternatively, which class is responsible for payload encoding? Maybe one
could create their own version which will not encode the payload?
Thanks,
Branko
Sean O'Callaghan wrote:
>
> Hi Branko,
>
> Take a look at the jaxws_dispatch_provider sample found in
> <CXF_HOME>\samples\jaxws_dispatch_provider
> The client code is similar to what you are trying to do.
>
> Seán.
>
>
--
View this message in context: http://www.nabble.com/Sending-XML-payload-without-encoding-it-tp21925398p21966828.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: Sending XML payload without encoding it
Posted by Sean O'Callaghan <SE...@progress.com>.
Hi Branko,
Take a look at the jaxws_dispatch_provider sample found in <CXF_HOME>\samples\jaxws_dispatch_provider
The client code is similar to what you are trying to do.
Seán.
-----Original Message-----
From: xbranko [mailto:xbranko@netscape.net]
Sent: 10 February 2009 00:41
To: users@cxf.apache.org
Subject: Sending XML payload without encoding it
Tried with both CXF 2.0.9 and 2.1.3:
I need to send payload that is XML. When I do, the content is encoded (i.e.
all '<' are replaced with <, '>' with > etc.), and the server throws
an exception because it doesn't expect payload to be encoded. I verified
that using soapui which sends the pure XML and receives correct answer from
the server.
Searching through the forum, I've implemented the alternative approach:
Service service = Service.create(new URL(wsdl), SERVICE_NAME);
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setNamespaceAware(true);
DocumentBuilder builder = factory.newDocumentBuilder();
InputStream is = new StringBufferInputStream(xmlPayload);
Document newDoc = builder.parse(is);
DOMSource request = new DOMSource(newDoc);
Dispatch<Source> disp = service.createDispatch(PORT_NAME,
Source.class, Service.Mode.PAYLOAD);
disp.getRequestContext().put(BindingProvider.SOAPACTION_USE_PROPERTY,
Boolean.TRUE);
disp.getRequestContext().put(BindingProvider.SOAPACTION_URI_PROPERTY,
"ServiceX");
Source result = disp.invoke(request);
With this approach, the server is returning:
"Unable to handle request without a valid action parameter. Please supply a
valid soap action."
I followed the code in the debugger, and saw that action parameter is being
set in the code, however, it does not get written out as part of the POST
request -- verified via the Network Protocol Analyzer -- the action is not
there.
Is there a third way? Ideally, I'd like to use the standard way, and just
indicate to CXF to do nothing with the payload, to just pass it through as
is.
Any help greatly appreciated!
--
View this message in context: http://www.nabble.com/Sending-XML-payload-without-encoding-it-tp21925398p21925398.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Sending XML payload without encoding it
Posted by Andrew Clegg <an...@nervechannel.com>.
Thanks for the very swift turnaround on this, Dan!
Andrew.
2009/3/12 Daniel Kulp <dk...@apache.org>:
> 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 <dk...@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 <an...@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 <xb...@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-tp219253
>> >>>>98 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
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
--
:: http://biotext.org.uk/ ::
Re: Sending XML payload without encoding it
Posted by Daniel Kulp <dk...@apache.org>.
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 <dk...@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 <an...@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 <xb...@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-tp219253
> >>>>98 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
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Sending XML payload without encoding it
Posted by Andrew Clegg <an...@nervechannel.com>.
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 <dk...@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 <an...@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 <xb...@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
Re: Sending XML payload without encoding it
Posted by Daniel Kulp <dk...@apache.org>.
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 <an...@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 <xb...@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
Re: Sending XML payload without encoding it
Posted by Andrew Clegg <an...@nervechannel.com>.
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 <an...@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 <xb...@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-tp21925398p22438203.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> :: http://biotext.org.uk/ ::
>
--
:: http://biotext.org.uk/ ::
Re: Sending XML payload without encoding it
Posted by xbranko <xb...@netscape.net>.
Andrew Clegg-2 wrote:
>
> 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?
>
>
Sorry I couldn't help you. In my case just passing the unencoded XML made
it work -- just for the fun of it, give it a try! I remember that I saw,
using debugger, that action was being set (somewhere deep in the CXF stack),
but it didn't get written as part of the POST request. If you have a small
and simple example that illustrates the problem, may be someone from the CXF
team can take a look and help.
--
View this message in context: http://www.nabble.com/Sending-XML-payload-without-encoding-it-tp21925398p22439233.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Sending XML payload without encoding it
Posted by Andrew Clegg <an...@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 <xb...@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-tp21925398p22438203.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
--
:: http://biotext.org.uk/ ::
Re: Sending XML payload without encoding it
Posted by xbranko <xb...@netscape.net>.
Forgot to mention that yourXML should be enclosed in the SOAP envelope:
String envOpen = "<env:Envelope
xmlns:env=\"http://schemas.xmlsoap.org/soap/envelope/\"\n " +
"xmlns:xs=\"http://www.w3.org/2001/XMLSchema\"\n" +
"xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"\n" +
"xmlns=\"your service
URL\">\n" +
"<env:Body>\n";
String envClose = "</env:Body>\n</env:Envelope>";
so, you'd have:
String xmlPayload = envOpen + <yourXML>...</yourXML> + envClose;
--
View this message in context: http://www.nabble.com/Sending-XML-payload-without-encoding-it-tp21925398p22438596.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Sending XML payload without encoding it
Posted by xbranko <xb...@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-tp21925398p22438203.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Sending XML payload without encoding it
Posted by Andrew Clegg <an...@nervechannel.com>.
I just found this message from last month...
How did you get the SOAPAction header thing to work in the end? I have
the same problem as you had -- I'm doing this in the code:
rc.put( BindingProvider.SOAPACTION_URI_PROPERTY, "string containing
soap action" );
rc.put( BindingProvider.SOAPACTION_USE_PROPERTY, true );
where rc is the RequestContext of my Dispatch object. But it isn't
appearing on the wire.
Thanks,
Andrew.
2009/2/10 xbranko <xb...@netscape.net>:
>
> Tried with both CXF 2.0.9 and 2.1.3:
>
> I need to send payload that is XML. When I do, the content is encoded (i.e.
> all '<' are replaced with <, '>' with > etc.), and the server throws
> an exception because it doesn't expect payload to be encoded. I verified
> that using soapui which sends the pure XML and receives correct answer from
> the server.
>
> Searching through the forum, I've implemented the alternative approach:
>
> Service service = Service.create(new URL(wsdl), SERVICE_NAME);
>
> DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
> factory.setNamespaceAware(true);
> DocumentBuilder builder = factory.newDocumentBuilder();
> InputStream is = new StringBufferInputStream(xmlPayload);
> Document newDoc = builder.parse(is);
> DOMSource request = new DOMSource(newDoc);
>
> Dispatch<Source> disp = service.createDispatch(PORT_NAME,
> Source.class, Service.Mode.PAYLOAD);
>
> disp.getRequestContext().put(BindingProvider.SOAPACTION_USE_PROPERTY,
> Boolean.TRUE);
> disp.getRequestContext().put(BindingProvider.SOAPACTION_URI_PROPERTY,
> "ServiceX");
>
> Source result = disp.invoke(request);
>
> With this approach, the server is returning:
> "Unable to handle request without a valid action parameter. Please supply a
> valid soap action."
>
> I followed the code in the debugger, and saw that action parameter is being
> set in the code, however, it does not get written out as part of the POST
> request -- verified via the Network Protocol Analyzer -- the action is not
> there.
>
> Is there a third way? Ideally, I'd like to use the standard way, and just
> indicate to CXF to do nothing with the payload, to just pass it through as
> is.
>
> Any help greatly appreciated!
> --
> View this message in context: http://www.nabble.com/Sending-XML-payload-without-encoding-it-tp21925398p21925398.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
--
:: http://biotext.org.uk/ ::
Re: Sending XML payload without encoding it
Posted by Daniel Kulp <dk...@apache.org>.
It SOUNDS like the SOAPAction header is either not being set on the wire or is
set wrong. Can you wireshark the transfer to make sure the SOAPAction is
properly set in the header. Also, check the wsdl for the server to make sure
"ServiceX" is the correct action for the method you are invoking.
Dan
On Mon February 9 2009 7:41:20 pm xbranko wrote:
> Tried with both CXF 2.0.9 and 2.1.3:
>
> I need to send payload that is XML. When I do, the content is encoded (i.e.
> all '<' are replaced with <, '>' with > etc.), and the server throws
> an exception because it doesn't expect payload to be encoded. I verified
> that using soapui which sends the pure XML and receives correct answer from
> the server.
>
> Searching through the forum, I've implemented the alternative approach:
>
> Service service = Service.create(new URL(wsdl), SERVICE_NAME);
>
> DocumentBuilderFactory factory =
> DocumentBuilderFactory.newInstance(); factory.setNamespaceAware(true);
> DocumentBuilder builder = factory.newDocumentBuilder();
> InputStream is = new StringBufferInputStream(xmlPayload);
> Document newDoc = builder.parse(is);
> DOMSource request = new DOMSource(newDoc);
>
> Dispatch<Source> disp = service.createDispatch(PORT_NAME,
> Source.class, Service.Mode.PAYLOAD);
>
> disp.getRequestContext().put(BindingProvider.SOAPACTION_USE_PROPERTY,
> Boolean.TRUE);
> disp.getRequestContext().put(BindingProvider.SOAPACTION_URI_PROPERTY,
> "ServiceX");
>
> Source result = disp.invoke(request);
>
> With this approach, the server is returning:
> "Unable to handle request without a valid action parameter. Please supply a
> valid soap action."
>
> I followed the code in the debugger, and saw that action parameter is being
> set in the code, however, it does not get written out as part of the POST
> request -- verified via the Network Protocol Analyzer -- the action is not
> there.
>
> Is there a third way? Ideally, I'd like to use the standard way, and just
> indicate to CXF to do nothing with the payload, to just pass it through as
> is.
>
> Any help greatly appreciated!
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog