Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <7277989.15861287693500865.JavaMail.jira@thor>
Date: Thu, 21 Oct 2010 16:38:20 -0400 (EDT)
From: "Henryk Konsek (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Updated: (EXEC-50) Pumping lines from the command output
In-Reply-To: <13701656.15811287693498321.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/EXEC-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henryk Konsek updated EXEC-50:
------------------------------

    Attachment: lines_listener.patch

> Pumping lines from the command output
> -------------------------------------
>
>                 Key: EXEC-50
>                 URL: https://issues.apache.org/jira/browse/EXEC-50
>             Project: Commons Exec
>          Issue Type: Improvement
>            Reporter: Henryk Konsek
>            Priority: Trivial
>         Attachments: lines_listener.patch
>
>
> My application makes heavy use of analyzing output lines of the long running executable. Executed command may run even up to to few hours. Actually I'm not so interested in the result of execution, but rather in the output produced by the program. Each line of the output contains some important data. I need to listen to these lines of the output, filter them and send JMS message containing selected of them.
> Current implementation of the StreamPumper makes it hard to listen to the output lines produced by the executable since it copies entire InputStream. What I did is pumping command output to the FilterInputStream and looking for the new line markers. It works for me, however it would be nice to have an ability to read entire lines from the PumpStream instead of raw bytes only. This is quite common case since executable usually format their output using the lines instead of the raw stream of bytes.
> I created patch refactoring StreamPumper to extend AbstractStreamPumper. I created also BufferedReaderPumper (also extending AbstractStreamPumper) to pump lines from the executable output and send them to the OutputLinesListener. I also extracted creation of the StreamPumper in the PumpStreamHandler to the factory method. This method can be overridden in order to use BufferedReaderPumper instead of default StreamPumper.
> What do you think about such approach?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.