cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Really Streaming objects to the service client
Date Sun, 25 Oct 2009 22:49:27 GMT
Well, let's see. AFAIK, none of the myriad of WS-* things that we have in
CXF directly addresses this, but you many be overly pessimistic about some
aspects. Are you SOAP-y on both ends, or is this a JAX-RS sort of business?

CXF doesn't always make temp files out of outgoing attachments. If you have
a DataHandler / DataSource, it will just pump the bytes.

HOWEVER, the client side raises harder problems. I'm imagining some sort of
custom interceptor that would grab the content before MTOM processing has a
chance to do whatever it normally does, and calls you back.

This all assumes that you are responsible for data format management; none
of the data bindings that I am familiar with can handle any concept of
incrementally unmarshalling objects and handing them to you.

People have whole object caching systems for this sort of thing ...

On Sun, Oct 25, 2009 at 6:35 PM, Ronald Pieterse
<ronaldpieterse@gmail.com>wrote:

>
> Hi,
>
> I have a question about streaming with CXF. I'm already using Attachments
> which works fine but now I need something even more powerful.
> I have a huge amount of objects that i retrieve from the database in a
> 'streaming' fashion (using Spring's ResultSetExtractor) and now I want to
> stream them directly to the client, per object if that is at all possible.
> I don't want to use an attachment because that would require a temp file or
> something like that. And it would also require me to change the signature
> of
> the call.
>
> What are my options here? I'm using CXF 2.1.4 btw.
> THNX
> --
> View this message in context:
> http://www.nabble.com/Really-Streaming-objects-to-the-service-client-tp26052541p26052541.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message