Thanks for that but I ended up implementing a custom
DOMDocumentProvider. I agree the DOMSource approach is more powerful
(subtrees and stuff) but it is also much less intuitive. You really
can get to do a lot of XML processing in Java without ever using that
class, unlike Document which seems like an obvious choice for a return
value of an XML web service. Just my 5 cents :)
On Thu, Jul 16, 2009 at 10:28 AM, Paul Sandoz<Paul.Sandoz_at_sun.com> wrote:
> Hi,
>
> Return a DOMSource.
>
> @GET
> @Produces("application/xml")
> public DOMSource get() {
> Document d = ..
> return new DOMSource(d);
> }
>
> Any instance of Source is supported which can be transformed to a
> StreamSource using TransformerFactory.
>
> Paul.
>
> On Jul 16, 2009, at 10:23 AM, Jacob wrote:
>
>> Hi Guys,
>>
>> There is no out-of-the-box org.w3c.dom.Document provider
>> (MsgBodyReader/Writer) in Jersey (at least not in 1.1.1-ea). You are
>> probably fully aware of this but nevertheless it seems like an
>> oversight to me. So basically you're not able to quickly write a most
>> obvious piece of code that comes to one's mind when writing a web
>> service:
>>
>> @GET
>> @Produces("application/xml")
>> public Document get() { ... return doc; };
>>
>> results in:
>>
>> A message body writer for Java type, class
>> com.sun.org.apache.xerces.internal.dom.DeferredDocumentImpl, and MIME
>> media type, application/xml, was not found
>>
>>
>> Any reason for that?
>>
>> --
>>
>> Cheers,
>> Jacob
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
--
Cheers,
Jakub