Re: org.apache.geronimo.system.main.Daemon and commons-cli
Not at all. I am now back from holiday and I am simply waiting for this week-end to check-in these changes. Thanks, Gianny On 03/05/2007, at 1:58 PM, Jason Dillon wrote: Sorry man, I've not had any time to look into this... its still on my list though ;-) --jason On Apr 3, 2007, at 6:45 AM, Gianny Damour wrote: Hi, As discussed with Jason, I worked on a fix to this problem: GERONIMO-3059. I will be on holiday, with sporadic internet access, for a couple of weeks starting tomorrow night; So, I will not check in these changes now as I will not be able to support related problems, if any. Having said that, Jason, if you are happy to check them in and fix related issues, if any, then I am fine with it :) Thanks, Gianny On 21/03/2007, at 11:05 AM, Sachin Patel wrote: I agree, this is a usability regression. -sachin On Mar 20, 2007, at 5:08 PM, Jason Dillon wrote: You have to wait several seconds for the bootstrap kernel to load... just to display the cli usage... that seems wrong IMO.
Re: org.apache.geronimo.system.main.Daemon and commons-cli
Sorry man, I've not had any time to look into this... its still on my list though ;-) --jason On Apr 3, 2007, at 6:45 AM, Gianny Damour wrote: Hi, As discussed with Jason, I worked on a fix to this problem: GERONIMO-3059. I will be on holiday, with sporadic internet access, for a couple of weeks starting tomorrow night; So, I will not check in these changes now as I will not be able to support related problems, if any. Having said that, Jason, if you are happy to check them in and fix related issues, if any, then I am fine with it :) Thanks, Gianny On 21/03/2007, at 11:05 AM, Sachin Patel wrote: I agree, this is a usability regression. -sachin On Mar 20, 2007, at 5:08 PM, Jason Dillon wrote: You have to wait several seconds for the bootstrap kernel to load... just to display the cli usage... that seems wrong IMO.
Re: org.apache.geronimo.system.main.Daemon and commons-cli
I will take a peek at GERONIMO-3059 and provide some feedback. Thanks :-) --jason On Apr 3, 2007, at 6:45 AM, Gianny Damour wrote: Hi, As discussed with Jason, I worked on a fix to this problem: GERONIMO-3059. I will be on holiday, with sporadic internet access, for a couple of weeks starting tomorrow night; So, I will not check in these changes now as I will not be able to support related problems, if any. Having said that, Jason, if you are happy to check them in and fix related issues, if any, then I am fine with it :) Thanks, Gianny On 21/03/2007, at 11:05 AM, Sachin Patel wrote: I agree, this is a usability regression. -sachin On Mar 20, 2007, at 5:08 PM, Jason Dillon wrote: You have to wait several seconds for the bootstrap kernel to load... just to display the cli usage... that seems wrong IMO.
Re: org.apache.geronimo.system.main.Daemon and commons-cli
Hi, As discussed with Jason, I worked on a fix to this problem: GERONIMO-3059. I will be on holiday, with sporadic internet access, for a couple of weeks starting tomorrow night; So, I will not check in these changes now as I will not be able to support related problems, if any. Having said that, Jason, if you are happy to check them in and fix related issues, if any, then I am fine with it :) Thanks, Gianny On 21/03/2007, at 11:05 AM, Sachin Patel wrote: I agree, this is a usability regression. -sachin On Mar 20, 2007, at 5:08 PM, Jason Dillon wrote: You have to wait several seconds for the bootstrap kernel to load... just to display the cli usage... that seems wrong IMO.
Re: org.apache.geronimo.system.main.Daemon and commons-cli
I agree, this is a usability regression. -sachin On Mar 20, 2007, at 5:08 PM, Jason Dillon wrote: You have to wait several seconds for the bootstrap kernel to load... just to display the cli usage... that seems wrong IMO.
Re: org.apache.geronimo.system.main.Daemon and commons-cli
On Mar 20, 2007, at 4:42 AM, Gianny Damour wrote: In the meantime... can anyone tell me why we are booting up a kernel before cli parsing? From what has congealed in my head so far... this is for access to the repository for classloading of bootstrap classes. Is there any other reason why we boot a kernel here before cli parsing? A kernel is booted before cli parsing so that classes parsing cli arguments do not need to be defined by the system classloader. Verbose level switches must be done prior to boot a Geronimo kernel as they control the default log level and this initialization must occur prior to acquire the first log instance. The bootstrap is simple as: load a boot configuration; get a Main implementation from it (or configurations restored when the boot configuration is loaded); and invoke execute(String args[]) on it. AFAIK, all the clis use this unified approach. So do we end up with 2 kernels after everything is booted? One for bootstrap and one for the real deal? Why is it "a wee bit more difficult" to add commons-cli now? Its just that cli processing is now scattered between a few classes over 2 modules at least for Daemon. There are also a bunch more classes, some with main() others w/o main()... which has me scratching my head to what this is actually doing. I'm also wondering what's the difference between Daemon and EmbeddedDaemon? What happens when users want to use a different repository location? I basically understand what is going on... but I think the order of how its being done is a odd. Like if you run: java -jar bin/server.jar --help You have to wait several seconds for the bootstrap kernel to load... just to display the cli usage... that seems wrong IMO. I would rather have commons-cli.jar and a tiny geronimo-cli.jar on the system classpath (along with the kernels requirements), process command-line options, then boot up the kernel and delegate to a bootstrapping Main to finish the job. --jason
Re: org.apache.geronimo.system.main.Daemon and commons-cli
On 20/03/2007, at 6:12 PM, Jason Dillon wrote: I briefly looked into adding this... but looks like a lot of the bootstrap plumbing has changed. I'm a bit bewildered as to why we are booting up a temporary kernel before we get to command-line option parsing. I'm also a bit mystified as to why option parsing is now spread over several classes. IMO the bootstrap has become overly complicated... and probably needs some love to get it sorted. The task of adding commons-cli to the single Daemon class has become a wee bit more difficult due to all of this, so I'm gonna put this off for a little bit more while I soak up all of the recent changes and let it congeal in my head. In the meantime... can anyone tell me why we are booting up a kernel before cli parsing? From what has congealed in my head so far... this is for access to the repository for classloading of bootstrap classes. Is there any other reason why we boot a kernel here before cli parsing? A kernel is booted before cli parsing so that classes parsing cli arguments do not need to be defined by the system classloader. Verbose level switches must be done prior to boot a Geronimo kernel as they control the default log level and this initialization must occur prior to acquire the first log instance. The bootstrap is simple as: load a boot configuration; get a Main implementation from it (or configurations restored when the boot configuration is loaded); and invoke execute(String args[]) on it. AFAIK, all the clis use this unified approach. Why is it "a wee bit more difficult" to add commons-cli now? Thanks, Gianny --jason On Feb 27, 2007, at 4:20 PM, Matt Hogstrom wrote: Sounds good. On Feb 26, 2007, at 9:02 PM, Jason Dillon wrote: Anyone mind if I re-write org.apache.geronimo.system.main.Daemon to use commons-cli to handle option processing? Use of commons-cli 1.0 add ~30k to the bootstrap classpath (uses commons-lang, which is already there), and will greatly simplify this code, and make it a little easier/nicer to add more command- line options in the future as well as providing. --jason
Re: org.apache.geronimo.system.main.Daemon and commons-cli
I briefly looked into adding this... but looks like a lot of the bootstrap plumbing has changed. I'm a bit bewildered as to why we are booting up a temporary kernel before we get to command-line option parsing. I'm also a bit mystified as to why option parsing is now spread over several classes. IMO the bootstrap has become overly complicated... and probably needs some love to get it sorted. The task of adding commons-cli to the single Daemon class has become a wee bit more difficult due to all of this, so I'm gonna put this off for a little bit more while I soak up all of the recent changes and let it congeal in my head. In the meantime... can anyone tell me why we are booting up a kernel before cli parsing? From what has congealed in my head so far... this is for access to the repository for classloading of bootstrap classes. Is there any other reason why we boot a kernel here before cli parsing? --jason On Feb 27, 2007, at 4:20 PM, Matt Hogstrom wrote: Sounds good. On Feb 26, 2007, at 9:02 PM, Jason Dillon wrote: Anyone mind if I re-write org.apache.geronimo.system.main.Daemon to use commons-cli to handle option processing? Use of commons-cli 1.0 add ~30k to the bootstrap classpath (uses commons-lang, which is already there), and will greatly simplify this code, and make it a little easier/nicer to add more command- line options in the future as well as providing. --jason
Re: org.apache.geronimo.system.main.Daemon and commons-cli
Sounds good. On Feb 26, 2007, at 9:02 PM, Jason Dillon wrote: Anyone mind if I re-write org.apache.geronimo.system.main.Daemon to use commons-cli to handle option processing? Use of commons-cli 1.0 add ~30k to the bootstrap classpath (uses commons-lang, which is already there), and will greatly simplify this code, and make it a little easier/nicer to add more command- line options in the future as well as providing. --jason
Re: org.apache.geronimo.system.main.Daemon and commons-cli
Makes since. It sucks we the help can't list them as separate options, but it is good enough as is. -dain On Feb 27, 2007, at 1:22 PM, Jason Dillon wrote: On Feb 27, 2007, at 1:07 PM, Dain Sundstrom wrote: Say what? Will -v, -vv and -vvv stop working? If yes, then I don't think we should switch as what we have is currently working fine. Sorry, perhaps I was unclear before. -v, -vv will continue to work (-vvv didn't work before, but will start to work after the change). What I was explain was pure semantics about which were options. Currently these are separate options: -v -vv With commons-cli using the posix parser, both of these become one option: -v Which can be given multiple times, as in: -vv -vvv - Works, basically the same as the '-v' option to SSH: -v Verbose mode. Causes ssh to print debugging messages about its progress. This is helpful in debugging connection, authentica- tion, and configuration problems. Multiple -v options increase the verbosity. The maximum is 3. The main difference is (other than how its implemented) is when looking a --help, it won't show a '-vv' option, just a '-v' option with some docs that specifying it more than once increases the verbosity. Another side affect is that one can also do: -v -v -v which ends up the same as: -vvv Make more sense now? --jason
Re: org.apache.geronimo.system.main.Daemon and commons-cli
Say what? Will -v, -vv and -vvv stop working? If yes, then I don't think we should switch as what we have is currently working fine. -dain On Feb 27, 2007, at 12:20 PM, Jason Dillon wrote: I don't believe there is anything which prevents the syntax from being the same... except, that the '-vv' and '-v' options end up merging into one '-v' option, which can be specified more than one to increase verbosity, so the usage of '-vv' is the same, but technically there would be no '-vv' option, just a '-v'. --jason On Feb 27, 2007, at 9:48 AM, Dain Sundstrom wrote: I don't care as long as you don't change the cli syntax. IIRC the code originally used commons cli, but someone removed it because it wasn't flexible enough. It was a very long time ago, so my memory is fuzzy. -dain On Feb 26, 2007, at 6:02 PM, Jason Dillon wrote: Anyone mind if I re-write org.apache.geronimo.system.main.Daemon to use commons-cli to handle option processing? Use of commons-cli 1.0 add ~30k to the bootstrap classpath (uses commons-lang, which is already there), and will greatly simplify this code, and make it a little easier/nicer to add more command- line options in the future as well as providing. --jason
Re: org.apache.geronimo.system.main.Daemon and commons-cli
On Feb 27, 2007, at 1:07 PM, Dain Sundstrom wrote: Say what? Will -v, -vv and -vvv stop working? If yes, then I don't think we should switch as what we have is currently working fine. Sorry, perhaps I was unclear before. -v, -vv will continue to work (-vvv didn't work before, but will start to work after the change). What I was explain was pure semantics about which were options. Currently these are separate options: -v -vv With commons-cli using the posix parser, both of these become one option: -v Which can be given multiple times, as in: -vv -vvv - Works, basically the same as the '-v' option to SSH: -v Verbose mode. Causes ssh to print debugging messages about its progress. This is helpful in debugging connection, authentica- tion, and configuration problems. Multiple -v options increase the verbosity. The maximum is 3. The main difference is (other than how its implemented) is when looking a --help, it won't show a '-vv' option, just a '-v' option with some docs that specifying it more than once increases the verbosity. Another side affect is that one can also do: -v -v -v which ends up the same as: -vvv Make more sense now? --jason
Re: org.apache.geronimo.system.main.Daemon and commons-cli
I don't believe there is anything which prevents the syntax from being the same... except, that the '-vv' and '-v' options end up merging into one '-v' option, which can be specified more than one to increase verbosity, so the usage of '-vv' is the same, but technically there would be no '-vv' option, just a '-v'. --jason On Feb 27, 2007, at 9:48 AM, Dain Sundstrom wrote: I don't care as long as you don't change the cli syntax. IIRC the code originally used commons cli, but someone removed it because it wasn't flexible enough. It was a very long time ago, so my memory is fuzzy. -dain On Feb 26, 2007, at 6:02 PM, Jason Dillon wrote: Anyone mind if I re-write org.apache.geronimo.system.main.Daemon to use commons-cli to handle option processing? Use of commons-cli 1.0 add ~30k to the bootstrap classpath (uses commons-lang, which is already there), and will greatly simplify this code, and make it a little easier/nicer to add more command- line options in the future as well as providing. --jason
Re: org.apache.geronimo.system.main.Daemon and commons-cli
I don't care as long as you don't change the cli syntax. IIRC the code originally used commons cli, but someone removed it because it wasn't flexible enough. It was a very long time ago, so my memory is fuzzy. -dain On Feb 26, 2007, at 6:02 PM, Jason Dillon wrote: Anyone mind if I re-write org.apache.geronimo.system.main.Daemon to use commons-cli to handle option processing? Use of commons-cli 1.0 add ~30k to the bootstrap classpath (uses commons-lang, which is already there), and will greatly simplify this code, and make it a little easier/nicer to add more command- line options in the future as well as providing. --jason
Re: org.apache.geronimo.system.main.Daemon and commons-cli
Sounds good 2 me. -sachin On Feb 26, 2007, at 9:02 PM, Jason Dillon wrote: Anyone mind if I re-write org.apache.geronimo.system.main.Daemon to use commons-cli to handle option processing? Use of commons-cli 1.0 add ~30k to the bootstrap classpath (uses commons-lang, which is already there), and will greatly simplify this code, and make it a little easier/nicer to add more command- line options in the future as well as providing. --jason
