You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Andrew Clegg <an...@nervechannel.com> on 2009/03/10 16:54:59 UTC
Re: Sending XML payload without encoding it
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 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.