[ 
https://issues.apache.org/jira/browse/CAMEL-9274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14982285#comment-14982285
 ] 

Claus Ibsen commented on CAMEL-9274:
------------------------------------

I wonder if we can hide the complexity a bit in a builder that the data format 
implementation uses

{code}
OutputStreamBuilder osb = OutputStreamBuilder.withExchange(exchange);

   ... code that writes to osb
   osb.write(...)

// and then call a build method or something that returns the wrapped stream 
instance
Object answer = osb.build();
return answer;
{code}

Then you dont need to have logic if its stream cache or not etc. Just use the 
builder and it facade it. The facade would have to delete the OutputStream api 
to the underlying whether its the stream cached or the byte array. Then the 
builder supports stream caching and fallback to a in memory byte array based.

Just a though

The builder can also have withStreamCaching, witeByteArray so the end user can 
use it in other cases where an exchange is not avaiable.


> StreamCache does not work correctly with MarshalProcessor and pretty much all 
> DataFormats
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-9274
>                 URL: https://issues.apache.org/jira/browse/CAMEL-9274
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.16.0
>            Reporter: Aaron Whiteside
>             Fix For: 2.17.0
>
>         Attachments: CAMEL_9274.patch
>
>
> StreamCache does not work correctly with MarshalProcessor and pretty much all 
> DataFormats
> # Documentation states that stream caching can be turned on, on a per route 
> basis. The places were we actually try and utilize stream caching only checks 
> if the global option is turned on (MarshalProcessor + PGPKeyAccessDataFormat, 
> I can't find any other meaningful attempts to use stream caching anywhere 
> else) not the per route setting.
> # Secondly, if we ignore the first problem, only one data formatter tries to 
> use stream caching for unmarshaling: PGPKeyAccessDataFormat. If you try and 
> unzip a large zip file it's contents will be decompressed into memory. The 
> same goes for any other large data formatter conversion (unmarshaling, only).
> Attached is a patch that corrects the first problem and part of the second 
> problem (ZipFileDataFormat, ZipDataFormat and PGPKeyAccessDataFormat).
> A separate issue should probably be opened to fix all the remaining 
> DataFormat implementation to support Stream Caching.
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to