[
https://issues.apache.org/jira/browse/IO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567523#action_12567523
]
David Smiley commented on IO-71:
--------------------------------
Sorry if I was not clear in my description. I do in fact use PipedInput &
Output streams within my code to do much of the work. I went to use them
straight-up on a project but then found some shortcomings (not necessarily a
problem for everyone out there but for my project any way). There are two
things that those JDK classes don't do: IOException and close() propagation.
The reader of a PipedInputStream won't get the actual IOException of the
problem if the other side of the pipe pukes for whatever reason. And closing
the PipedInputStream doesn't close a source InputStream from where the data
actually came from in the first place. And by the way, the reading and writing
needs to occur on separate threads which can be awkward. My PipedUtils wraps
that up neatly to make all this easy. See PipedUtilsTest which goes back and
forth through this process with a a bear minimum of code.
> [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.
