Looking for a solution for Large XML Messages - streaming and JAXWS

[Saniya Afaq <sa...@actividentity.com>]

Hi,

I'm using Metro 1.3 with JDK 1.5.x.

I need a solution for streaming large messages - currently in my
solution - we stream large messages by using the Provider API -
dispatching the XML file from the client to the server side. 

However on the server side we receive a StaxSource object - and it is
not possible to retrieve a stream from that object. I had to do the
following in my code - but it doesn't seem like the right solution since
i do not want to write out all the binary data in memory in the
ByteOutputStream... Does Metro provide some way of going about it -
since the whole purpose of Provider API is to enable us to handle large
messages --

ByteArrayOutputStream bos = new ByteArrayOutputStream();
StreamResult streamResult = new StreamResult(bos);
Transformer trans = TransformerFactory.newInstance().newTransformer();
trans.transform(inSource, streamResult);
bos.close();
ByteArrayInputStream in = new ByteArrayInputStream(bos.toByteArray()); 


Any help would be great!
Thanks
Saniya

Re: Looking for a solution for Large XML Messages - streaming and JAXWS

[Glen Mazza <gl...@gmail.com>]

Andrew Clegg wrote:
> 
> 2008/11/12 Saniya Afaq <sa...@actividentity.com>:
>> Hi,
>>
>> I'm using Metro 1.3 with JDK 1.5.x.
> 
> This is the Apache CXF mailing list. Metro is a completely different
> implementation of JAX-WS, by Sun!
> 

That's OK--I told Saniya to ask here as well as Metro, as there may be more
ideas on this list.


Andrew Clegg wrote:
> 
> In CXF you can implement Provider<StreamSource>, giving you an invoke
> method which takes and receives a StreamSource:
> 
> public StreamSource invoke( StreamSource request ) ...
> 
> You can read out of this with an XMLStreamReader. I've sent/received
> messages with over 10Mb of XML like this. I assume you can do this in
> Metro as well.
> 
> BTW you know StAXSource has a getXMLStreamReader() method, right? So
> you can probably just do that.
> 
> Andrew.
> 

Actually, Metro might *not* have a Provider<StreamSource> option, so perhaps
Saniya might want to look at using Apache CXF instead.  I mention this
because on the Dispatch (client) side at least, there are more options[1]
for CXF than Metro in this regard:  Dispatch<DOMSource>,
Dispatch<SAXSource>, and Dispatch<StreamSource>

Glen

[1]
http://www.jroller.com/gmazza/entry/writing_junit_test_cases_for#testepex ,
see method "doubleItWorksForPrimeNumbers()".

-- 
View this message in context: http://www.nabble.com/Looking-for-a-solution-for-Large-XML-Messages---streaming-and-JAXWS-tp20451942p20459857.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Looking for a solution for Large XML Messages - streaming and JAXWS

[Andrew Clegg <an...@gmail.com>]

2008/11/12 Saniya Afaq <sa...@actividentity.com>:
> Hi,
>
> I'm using Metro 1.3 with JDK 1.5.x.

This is the Apache CXF mailing list. Metro is a completely different
implementation of JAX-WS, by Sun!

> I need a solution for streaming large messages - currently in my
> solution - we stream large messages by using the Provider API -
> dispatching the XML file from the client to the server side.
>
> However on the server side we receive a StaxSource object - and it is
> not possible to retrieve a stream from that object. I had to do the
> following in my code - but it doesn't seem like the right solution since
> i do not want to write out all the binary data in memory in the
> ByteOutputStream... Does Metro provide some way of going about it -
> since the whole purpose of Provider API is to enable us to handle large
> messages --

In CXF you can implement Provider<StreamSource>, giving you an invoke
method which takes and receives a StreamSource:

public StreamSource invoke( StreamSource request ) ...

You can read out of this with an XMLStreamReader. I've sent/received
messages with over 10Mb of XML like this. I assume you can do this in
Metro as well.

BTW you know StAXSource has a getXMLStreamReader() method, right? So
you can probably just do that.

Andrew.