An interesting generalization of "getting the data from the FileUploadPlugin, read it from the filesystem" would be "getting the data from an arbitrary set of bourne/bash-shell pipeline commands" , (which would be implicitly available in unix/linux, or through cygwin on windows). Alternately, instead of using a sub-shell or sub-process, a better implementation is using native java ssh with passwordless public-key authentication to special no-login command-only accounts (e.g. http://www.jcraft.com/jsch using " Userauth: publickey(DSA,RSA)" feature). This allows a specified and restricted set of shell commands to run in a restricted environment/shell on specific machines on the subnet, all under the same ssh-keygen(1) generated passwordless authentication. Even if running the commands locally, not running the subprocesses under tomcat's UID is a good idea from security standpoint -- per http://en.wikipedia.org/wiki/Principle_of_least_privilege and http://en.wikipedia.org/wiki/Privilege_separation . One can imagine an abstract superclass which implements all the plumbing behind an asychronous subprocess-running -management and -output collection utility. Concrete classes would instantiate a subprocess, and have methods for sending messages to the subprocess, as well as asynchronous parsing of subprocess output (perhaps using a callback-type function that returns an object each time a parseable-unit returns from the subprocess). You'd also define a class whose instances contained each parseable unit, as well as regexps which would attempt to match each line of output from the subprocess, returning an instance for each match. Extra credit for wrapping it all in an AJAXy interface that modelessly allows asychronous updating of output from long-running shell subprocesses, with an option to cancel, and automatic termination of subprocess upon exit of page. It is important that one that avoids using fork()/vfork() out of a native method on each subprocess invocation. This is best handled by having the instance initializer spawn a java-based SSH command-shell thread associated with the subprocess instance. (IMHO calling vfork/exec in java repeatedly might have different performance implications today than it did in the early days of unix when a gigabyte resident tomcat java session would have been unthinkable... so let the SSH shell and command-only accounts handle the system&security aspects, and just have a java reader thread select() off the output from the subprocess connection.) Another potential implementation of "arbitrary subprocess" access can be done through "expect" style applications, though the fork/exec issues should be investigated further before going down this path. The google implementation below that seems to implement TCL in Java as part of it's solution seems like megalomaniacal overkill http://code.google.com/p/expect4j/ http://expectj.sourceforge.net/ . The expectj solution looks useful and less rube-goldbergian: see for example http://expectj.sourceforge.net/user_documentation_1.0.html contains a simple expectj script that logs in to a remote machine and deletes a file.... -- Niels http://nielsmayer.com On Wed, Apr 23, 2008 at 6:52 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: