Hi,
On 10/11/11 06:14, Craig Dickson wrote:
Hi,
I am working on a project where a 3rd party has a .NET environment running that
is providing REST style services that send and receive XML over HTTP. My side
of the project is actually in Java on a separate machine entirely and we are
using CXF to talk to the services with the built in JAXB support as the
provider.
By default CXF appears to set the "Content Type" header of an XML request to
"application/xml". We have also tested adding an @Consumes annotation to the method and setting it
to "text/xml" and everything works fine on the CXF side. This is not surprising as these are the
acceptable types for XML.
J
However, now the .NET team is saying that it must be "text/plain" instead
otherwise their server will reject the request and they don't seem to be able to or know
how to change this setup.
We tried using the @Consumes annotation and setting it to "text/plain" but not
surprisingly CXF complains that it does not have a provider registered for that type.
So, two questions:
1. If it is possible at all, what would be the easiest way to configure CXF to send XML
documents with a Content Type header of "text/plain"?
You can update JAXBElementProvider to support additional types using a
producesTypes property:
<util:list id="producesTypes">
<value>application/xml</value>
<value>text/xml</value>
<value>text/plain</value>
</util:list>
<bean id="jaxbProvider"
class="org.apache.cxf.jaxrs.provider.JAXBElementProvider">
<property name="produceMediaTypes" ref="producesTypes"/>
<!-- if needed: -->
<property name="consumeMediaTypes" ref="consumesTypes"/>
-->
</bean>
and register it with jaxrs:client or using JAXRSClientFactory (or
WebClient.create(...)).
That should do it, alternatively you can do something like this:
WebClient.getConfig(proxy).getHttpConduit().getClient().setContentType("text/plain")
which bypasses the jaxrs runtime.
2. What are the implications of sending XML over HTTP using plain/text as the Content
Type? Are there any subtle "gotchas", or is it no big deal?
Most likely any receiver which does expect the proper */xml types won't
work, so configuring the provider as suggested above would be better if
Content-Type had to be set on the server side, when returning the
response...
HTH, Sergey
Thanks
