On Fri, Nov 27, 2009 at 7:16 AM, Robert Koberg <rob_at_koberg.com> wrote:
> ufff... my mail client keeps choosing the wrong address to reply (more inline below)
>
>
> On Nov 26, 2009, at 4:16 PM, Tatu Saloranta wrote:
>
>> On Tue, Nov 24, 2009 at 5:15 AM, Robert Koberg <rob_at_koberg.com> wrote:
>>> Hi,
>>>
>> ...
>>> I think that the message body writer would be the most useful as it can output pretty much anything. The main problem being is that it would not be as fast as directly streaming the result.
>>
>> How so? Message body readers and writers operate on streams, so this
>> should not be a problem?
>
> First there is the jaxb parse to the object. Then you use javax.xml.bind.util.JAXBSource
> for the transform. The XSL processor will parse that into an internal (optimized) DOM to operate on. In other words, you don't go straight to the output stream, but have an additional parse along the way.
Right, if you do use data binding. But you don't have to do that:
MessageBodyReaders and writer take InputStream/OutputStream, and it is
up to implementation to do whatever it is to do. There is no automatic
JAXB binding being done, it's just that default reader/writer
implementations do that.
So just pipe in stream into XSL processor, which will use whatever is
fastest way (Saxon builds its own TinyTree, Xalan probably something
similar).
However... if you do need to operate on objects for main biz logic,
and then do xml processing, there is no avoiding some level of
buffering. It's just it's not mandated by JAX-RS API per se.
>> But they do operate on lower level of abstraction so it would be more
>> work to plug those in.
>>
>> For output you can also use StreamingOutput, which allows for some
>> post processing.
>
> Yea, I might need some help it seems :) I was looking at Jackson's JacksonJsonProvider and didn't really understand why you needs to do everything you are doing (the untouchables, unreadables, unwritables). I haven't had a chance to get too deep though.
Untouchables are only needed to avoid binding 'primitive' types,
Strings, streams etc.
Personally I would actually want to handle them, but others may want
to add alternative handlers for these. That is: those are needed to
avoid collision between alternate readers/writers, when JAX-RS
containers needs to know which one to apply to given request and
response.
You don't really have to do that. However, the question of how to mix
and match other processing with XSLT is valid.
But maybe you could use filters for this purpose instead?
-+ Tatu +-