Re: [exec] Design of commons-exec
On 8/6/05, Niklas Gustavsson [EMAIL PROTECTED] wrote: Hi Jerome Thanks for a lot of really good feedback and ideas! I will come back to some of the other stuff later on, but first I think we need to discuss on of the points you bring up: jerome lacoste wrote: * run on the oldest SDK possible I think there are three ways to go: 1. Full support for 1.1+ 2. Limited support for 1.1-1.2, full support for 1.3+ 3. No support for 1.1-1.2, full support 1.3+ go for 3 'oldest' I really meant not SDK 5.0 only. J - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
jerome lacoste wrote: 1. Full support for 1.1+ 2. Limited support for 1.1-1.2, full support for 1.3+ 3. No support for 1.1-1.2, full support 1.3+ go for 3 'oldest' I really meant not SDK 5.0 only. Great, no 3 seems to be the favorite. I'll remove the stuff needed for 1.1 support (like the script-based CommandLaunchers) and send a new patch. /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
Hi Jerome Thanks for a lot of really good feedback and ideas! I will come back to some of the other stuff later on, but first I think we need to discuss on of the points you bring up: jerome lacoste wrote: * run on the oldest SDK possible I think there are three ways to go: 1. Full support for 1.1+ 2. Limited support for 1.1-1.2, full support for 1.3+ 3. No support for 1.1-1.2, full support 1.3+ Runtime.exec(String[] cmd, String[] env, File workingDir) was added in 1.3. A lot of the Ant trickery going on the the current code is to handle working directories on older (pre 1.3) JVMs. This include most of the CommandLaunchers and the shell/Perl scripts. The middle road would be to only support execution in the current directory only on 1.1. So, what do you all think? I'm personally lucky enough to mostly be on 1.3 and 1.4 these days, but I'm fine with either choice here. If you think we should aim for 1.1, I would prefer option 2 to ease our pains a little bit. If we make the CommandLaunchers pluggable (and I think we should), someone who would really need working directory support on 1.1 could potentially write their own CommandLauncher. /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
On Sat, Aug 06, 2005 at 01:18:08AM +0200, Niklas Gustavsson wrote: Hi Jerome Thanks for a lot of really good feedback and ideas! I will come back to some of the other stuff later on, but first I think we need to discuss on of the points you bring up: jerome lacoste wrote: * run on the oldest SDK possible I think there are three ways to go: 1. Full support for 1.1+ 2. Limited support for 1.1-1.2, full support for 1.3+ 3. No support for 1.1-1.2, full support 1.3+ Runtime.exec(String[] cmd, String[] env, File workingDir) was added in 1.3. A lot of the Ant trickery going on the the current code is to handle working directories on older (pre 1.3) JVMs. This include most of the CommandLaunchers and the shell/Perl scripts. The middle road would be to only support execution in the current directory only on 1.1. So, what do you all think? I'm personally lucky enough to mostly be on 1.3 and 1.4 these days, but I'm fine with either choice here. If you think we should aim for 1.1, I would prefer option 2 to ease our pains a little bit. If we make the CommandLaunchers pluggable (and I think we should), someone who would really need working directory support on 1.1 could potentially write their own CommandLauncher. I really see no need to support anything below 1.3. Even 1.3 support is not something that I would put very much effort into. -- Trygve signature.asc Description: Digital signature
Re: [exec] Design of commons-exec
2 or 3 for me. Sun no longer support them, and I don't think anyone would be developing new code for them. I don't think commons-exec would be an important thing to have running on the MS VM :) - Brett Niklas Gustavsson wrote: Hi Jerome Thanks for a lot of really good feedback and ideas! I will come back to some of the other stuff later on, but first I think we need to discuss on of the points you bring up: jerome lacoste wrote: * run on the oldest SDK possible I think there are three ways to go: 1. Full support for 1.1+ 2. Limited support for 1.1-1.2, full support for 1.3+ 3. No support for 1.1-1.2, full support 1.3+ Runtime.exec(String[] cmd, String[] env, File workingDir) was added in 1.3. A lot of the Ant trickery going on the the current code is to handle working directories on older (pre 1.3) JVMs. This include most of the CommandLaunchers and the shell/Perl scripts. The middle road would be to only support execution in the current directory only on 1.1. So, what do you all think? I'm personally lucky enough to mostly be on 1.3 and 1.4 these days, but I'm fine with either choice here. If you think we should aim for 1.1, I would prefer option 2 to ease our pains a little bit. If we make the CommandLaunchers pluggable (and I think we should), someone who would really need working directory support on 1.1 could potentially write their own CommandLauncher. /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
Thanks a lot to Eric for pointing me to this thread. As he said, I started a similar project some weeks ago and put some notes to share on http://www.coffeebreaks.org/blogs/?p=8. I would have preferred more feedback from the jakarta guys before going further. Looks like my wishes are coming true :) In the proposal, I wrote some requirements and design ideas. Maybe the design ideas are too far from the original Ant classes. But I believe the requirements should still hold for commons-exec. So I paste them below: Requirements features (proposal) * handles the definition of a command line and its running in a flexible framework * minimal external dependencies (0 if possible) * run on the oldest SDK possible * increased thread safety * POJO objects where appropriate * extension friendly * automatic handling of command execution timeout * library should not be in the way of clients. E.g. possibility for clients to monitor or kill underlying processes * test friendly. In particular easy to mock the running of a command line, e.g. replacing Process inputs/outputs with normal streams. Maybe provide some mocks as part of the lib or in a jcli-mock lib. [...] Do not forget to look into the new SDK 1.5 ProcessBuilder class. One of the main issue CruiseControl is having today is in the Process handling. In this server side environment, timeouts are not always practical and we need to give the user more control. So we need a Process Destroyer like facility, not something automated that is executed when the VM terminates, but something that gives more control over the life/death of the processes. Some kind of user triggered watchdog instead of a timeout triggered one. The design ideas I tried to describe on the aforementionned page are focused on trying to solve this issue. They are probably a little bit too complex. Nevertheless feel free to comment on them. Answers to your questions: * Do you think this fits with what you would find appropriate and useful for commons-exec? Sounds good to me. Except the Process destroyer as pointed by others. * Would it be a good starting point (if so I'll create a patch for the code I've cleaned up and removed the Ant specifics from)? a patch or a tarball? Is there some code already somewhere today outside of Ant's repository? * Should I put this on the wiki for further discussions? If you do so, please send the URL. I am not sure if I can contribute directly to this library, but you can be assured that I will use it as soon as there's something usable, to make sure it fixes out issues in CruiseControl. Thanks for taking the initiative! Cheers, Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
Brett Porter wrote: * Would it be a good starting point (if so I'll create a patch for the code I've cleaned up and removed the Ant specifics from)? I think so. Cool, I'll get you a SVN patch tonight to get started. /niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
On 01/08/05, Niklas Gustavsson [EMAIL PROTECTED] wrote: ... This is a very short description of the cleaned up Ant exec task design: ... * Process destroyer: adds itself as a shutdown hook, Execute adds and removes created processes to ensure that they are correctly destroyed when the JVM stops. I'm sure it works in Ant but I'm worry about using such solution in server-side applications where JVM (in therory) do not stop - just application is being redeployed over and over. Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
Tomasz Pik wrote: * Process destroyer: adds itself as a shutdown hook, Execute adds and removes created processes to ensure that they are correctly destroyed when the JVM stops. I'm sure it works in Ant but I'm worry about using such solution in server-side applications where JVM (in therory) do not stop - just application is being redeployed over and over. I agree. Right now everything is tuned for Ant-type applications (quick runs). In the case of long-runnings JVMs a Watchdog is more appropriate. In the current code I got the ProcessDestroyer is not optional but I'll make a note of fixing that. Thanks! /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
On Tue, 2005-08-02 at 16:18 +0200, Niklas Gustavsson wrote: Tomasz Pik wrote: * Process destroyer: adds itself as a shutdown hook, Execute adds and removes created processes to ensure that they are correctly destroyed when the JVM stops. I'm sure it works in Ant but I'm worry about using such solution in server-side applications where JVM (in therory) do not stop - just application is being redeployed over and over. I agree. Right now everything is tuned for Ant-type applications (quick runs). In the case of long-runnings JVMs a Watchdog is more appropriate. In the current code I got the ProcessDestroyer is not optional but I'll make a note of fixing that. The folks developing Continuum would certainly like to help work on something that is usable in a server environment. We use some command line utilities to call various build tools and we'd love to be able to use the tool developed here instead of maintaining our own (which we borrowed from CruiseControl -- some other people that might want to help contribute to this cause). Thanks! /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Three people can keep a secret provided two of them are dead. -- Unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
Jerome Lacoste wrote a proposal a couple months ago to the CruiseControl mailing list talking about the same basic idea. His proposal is here: http://www.coffeebreaks.org/blogs/?p=8. I will forward this thread to him as he might be very interested in contributing. At any rate, something like this in Jakarta Commons would be great, I know I am using at least three different implementations of the same basic functionality! Eric Pugh On Aug 1, 2005, at 7:04 PM, Kev Jackson wrote: This is a very short description of the cleaned up Ant exec task design: * Exec: the former Ant task class used to create and configure Execute instances. Now mainly a convience class for starting new Execute instances. * Execute: the main class for running one process. Handles creation and configuration of the necessary objects (stream pump, watchdog, process destroyer). Can wait for the full execution time to enable synchronous return of the process return code or spawn a process to run async. * Process destroyer: adds itself as a shutdown hook, Execute adds and removes created processes to ensure that they are correctly destroyed when the JVM stops. * WatchDog: used to time out a running process. After a given time has passed, the process is checked if it's still running and there after destroyed. * CommandLauncher: a family of classes for actually starting the processes. Implementations exist for e.g. Java 1.1, Java 1.3, WinNT, Mac, VMS and so on. These classes handles the platform specifics. * Environment: used to retrive the current environment as well as setting new environment variables. Reading the current environment is done using platform specific commands (e.g. cmd /c set, env, /bin/env) and parsing the result. This could of course be improved on J2SE 5.0 to use System.getenv() instead. * StreamPumper: used to read/write the three stream (in, out, error) simultaniously. * CommandLine: class for handling (e.g. parsing, quoting) command lines. It might be worth extracting the interface from Ant, creating an implementation (using the interface) and then using this in a branch of Ant just to test that we've extracted all the necessary functionality. IIRC Environment is really derived through JavaEnvUtils (though I'll have to check source). A common interface for a commandLine would allow us to create platform specific commandLines depending on environment 2c Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[exec] Design of commons-exec
Hi Lets start the discussions on the design of commons-exec. I'll start by describing the Ant implementation that I think is the most mature out there. I also think it contains the bits that would be approriate for this package. This is a very short description of the cleaned up Ant exec task design: * Exec: the former Ant task class used to create and configure Execute instances. Now mainly a convience class for starting new Execute instances. * Execute: the main class for running one process. Handles creation and configuration of the necessary objects (stream pump, watchdog, process destroyer). Can wait for the full execution time to enable synchronous return of the process return code or spawn a process to run async. * Process destroyer: adds itself as a shutdown hook, Execute adds and removes created processes to ensure that they are correctly destroyed when the JVM stops. * WatchDog: used to time out a running process. After a given time has passed, the process is checked if it's still running and there after destroyed. * CommandLauncher: a family of classes for actually starting the processes. Implementations exist for e.g. Java 1.1, Java 1.3, WinNT, Mac, VMS and so on. These classes handles the platform specifics. * Environment: used to retrive the current environment as well as setting new environment variables. Reading the current environment is done using platform specific commands (e.g. cmd /c set, env, /bin/env) and parsing the result. This could of course be improved on J2SE 5.0 to use System.getenv() instead. * StreamPumper: used to read/write the three stream (in, out, error) simultaniously. * CommandLine: class for handling (e.g. parsing, quoting) command lines. There are additional classes but the list above are those of main interest. * Do you think this fits with what you would find appropriate and useful for commons-exec? * Would it be a good starting point (if so I'll create a patch for the code I've cleaned up and removed the Ant specifics from)? * Should I put this on the wiki for further discussions? /niklas -- Niklas Gustavsson [EMAIL PROTECTED] http://www.protocol7.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
Hi Niklas, * Do you think this fits with what you would find appropriate and useful for commons-exec? This sounds pretty good to me. Thanks for jumping o nthis, I was about to start one today when I saw your mail. One thing I'd like to see is the interfaces for CommandLauncher, CommandLine and Execute * Would it be a good starting point (if so I'll create a patch for the code I've cleaned up and removed the Ant specifics from)? I think so. * Should I put this on the wiki for further discussions? I'm fine with keeping it on the ML, or using the wiki - either way. Probably not subscribed to the right pages so let me know if you do create something there. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [exec] Design of commons-exec
This is a very short description of the cleaned up Ant exec task design: * Exec: the former Ant task class used to create and configure Execute instances. Now mainly a convience class for starting new Execute instances. * Execute: the main class for running one process. Handles creation and configuration of the necessary objects (stream pump, watchdog, process destroyer). Can wait for the full execution time to enable synchronous return of the process return code or spawn a process to run async. * Process destroyer: adds itself as a shutdown hook, Execute adds and removes created processes to ensure that they are correctly destroyed when the JVM stops. * WatchDog: used to time out a running process. After a given time has passed, the process is checked if it's still running and there after destroyed. * CommandLauncher: a family of classes for actually starting the processes. Implementations exist for e.g. Java 1.1, Java 1.3, WinNT, Mac, VMS and so on. These classes handles the platform specifics. * Environment: used to retrive the current environment as well as setting new environment variables. Reading the current environment is done using platform specific commands (e.g. cmd /c set, env, /bin/env) and parsing the result. This could of course be improved on J2SE 5.0 to use System.getenv() instead. * StreamPumper: used to read/write the three stream (in, out, error) simultaniously. * CommandLine: class for handling (e.g. parsing, quoting) command lines. It might be worth extracting the interface from Ant, creating an implementation (using the interface) and then using this in a branch of Ant just to test that we've extracted all the necessary functionality. IIRC Environment is really derived through JavaEnvUtils (though I'll have to check source). A common interface for a commandLine would allow us to create platform specific commandLines depending on environment 2c Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
