[
https://issues.apache.org/jira/browse/IO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567562#action_12567562
]
Jukka Zitting commented on IO-71:
---------------------------------
I see your point about the standard pipe streams, but I'd rather solve that by
implementing alternate versions of those classes in o.a.c.io.input and
o.a.c.io.output, just like the improved ByteArrayOutputStream and the proxy
stream classes do.
As for your actual PipedUtils API, it seems to me that you're rather looking
for a generic filtering mechanism. All your public methods take an InputStream,
apply some (piped) transformations to it, and return another InputStream for
reading content that has gone through those transformations.
The interesting part in your solution is IMHO the way you turn an OutputStream
filter into an InputStream filter, but I think that with some refactoring you
could achieve the same functionality without the extra thread.
> [io] PipedUtils
> ---------------
>
> Key: IO-71
> URL: https://issues.apache.org/jira/browse/IO-71
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
> Environment: Operating System: All
> Platform: All
> Reporter: David Smiley
> Priority: Minor
> Fix For: 2.x
>
> Attachments: PipedUtils.zip
>
>
> I developed some nifty code that takes an OutputStream and sort of reverses
> it as if it were an
> InputStream. Error passing and handling close is dealt with. It needs
> another thread to do the work
> which runs in parallel. It uses Piped streams. I created this because I
> had to conform
> GZIPOutputStream to my framework which demanded an InputStream.
> See URL to source.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
