Jason Dillon wrote: > So, is this something that I should pursue? I've seen a few positive > comments on this functionality, nothing negative... > > Should I invest more time in making this feature complete and set it up > as the default system for launching the server?
Yes! > > --jason > > > On Aug 21, 2007, at 3:05 PM, Jeff Genender wrote: > >> Oh man this is sweet... >> >> I'd *really* like to see this in 2.0.2... >> >> Jeff >> >> Jason Dillon wrote: >>> Hiya folks, I finally got around to finishing up my POC of using GShell >>> to launch the Geronimo Server and I have committed the bits that make it >>> work to server/trunk. The new module which contains the GShell command >>> implementation (and support) classes is: >>> >>> modules/geronimo-commands >>> >>> And a new assembly which has the GShell bits all in place for folks to >>> test with is: >>> >>> assemblies/geronimo-jetty6-javaee5-gshell >>> >>> The assembly is not hooked up by default, but the code module is. So, >>> to test it out, you need to do something like: >>> >>> svn co https://svn.apache.org/repos/asf/geronimo/server/trunk server >>> cd server >>> mvn >>> assemblies/geronimo-jetty6-javaee5-gshell >>> mvn >>> >>> Then unzip the assembly: >>> >>> unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip >>> >>> And then finally try it out. First lets get the basic GShell >>> command-line help: >>> >>> ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help >>> >>> This should spit out something like: >>> >>> <snip> >>> ____ ____ _ _ _ >>> / ___/ ___|| |__ ___| | | >>> | | _\___ \| '_ \ / _ \ | | >>> | |_| |___) | | | | __/ | | >>> \____|____/|_| |_|\___|_|_| >>> >>> GShell -- Geronimo command-line shell >>> >>> usage: gsh [options] <command> [args] >>> -n,--non-interactive Run in non-interactive mode >>> -D,--define <name=value> Define a system property >>> -V,--version Display GShell version >>> -c,--commands <string> Read commands from string >>> -debug,--debug Enable DEBUG logging output >>> -h,--help Display this help message >>> -i,--interactive Run in interactive mode >>> -quiet,--quiet Limit logging output to ERROR >>> -verbose,--verbose Enable INFO logging output >>> </snip> >>> >>> Then lets run the interactive-shell: >>> >>> ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh >>> >>> This should leave you at a very plain prompt at the moment: >>> >>> <snip> >>>> _ >>> </snip> >>> >>> At this point you can type something like this to list all of the known >>> commands: >>> >>> <snip> >>> help commands >>> </snip> >>> >>> Which should spit back: >>> >>> <snip> >>> Available commands (and aliases): >>> start-server ( start ) >>> set >>> exit ( quit, bye ) >>> unset >>> source >>> help >>> </snip> >>> >>> The command that I added is called 'start-server', with an alias of >>> 'start'. This is basically an augmented and enhanced version of what >>> the geronimo:start-server goal does in the geronimo-maven-plugin. To >>> see its options run this: >>> >>> <snip> >>> start-server --help >>> </snip> >>> >>> And it says: >>> >>> <snip> >>> start-server -- Starts a new Geronimo server instance >>> >>> usage: start-server [options] >>> -A,--javaagent <jar> Use a specific Java Agent, set to >>> 'none' to >>> disable >>> -D,--property <name=value> Set a system property >>> -H,--home <dir> Use a specific Geronimo home directory >>> -J,--javaopt <option> Set a JVM flag >>> -b,--background Run the server process in the >>> background. >>> -h,--help Display this help message >>> -j,--jvm <dir> Use a specific Java Virtual Machine >>> for server >>> process >>> -l,--logfile <file> Capture console output to file >>> -m,--module <name> Start up a specific module by name. >>> -q,--quiet Suppress informative and warning >>> messages >>> -t,--timeout <seconds> Specify the timeout for the server >>> process in >>> seconds >>> -v,--verbose Enable verbose output; specify >>> multipule times >>> to increase verbosity. >>> </snip> >>> >>> NOTE: Use -vv for --veryverbose ;-) >>> >>> And then give it a whirl and try to start the server up from the shell: >>> >>> <snip> >>> start-server >>> </snip> >>> >>> or if you prefer more output: >>> >>> <snip> >>> start-server -v >>> </snip> >>> >>> And so on... >>> >>> This will actually create a newly forked JVM to run the server in, and >>> will eventually have a robust node manager thingy, but I've not done >>> that yet ;-) >>> >>> The platform scripts are now super simple!!! All of the logic is now in >>> the command implementation. And eventually we can probably have the >>> geronimo-maven-plugin just invoke the command so that *everything* uses >>> the exact same method for launching the server process. >>> >>> * * * >>> >>> As requested by Jeff, I added support to read in some scripts to augment >>> the launching of the server... so that plugins can add properties and >>> such easily. Right now this is the directory which is inspected for >>> scripts: >>> >>> etc/rc.d >>> >>> And currently the scripts need to be named like this: >>> >>> <command-name>,<custom>.groovy >>> >>> I've created a default one for you to look at: >>> >>> etc/rc.d/start-server,default.groovy >>> >>> Which simply sets the max heap size to 512m: >>> >>> <snip> >>> command.javaFlags << '-Xmx512m' >>> </snip> >>> >>> When running the start-server command (or its aliases) all of the >>> etc/rc.d/start-server,*.groovy scripts are run (if any) before the >>> process is launched to allow the command.properties, command.javaFlags >>> and other bits to be augmented. >>> >>> These are Groovy scripts so you can also execute any arbitrary logic to >>> perform more complex setup muck if needed. >>> >>> * * * >>> >>> For now I just dropped all of the jars required for this into lib/gshell >>> and left lib/* alone, since the command uses the normal invoke of java >>> -jar server.jar and it requires bits in lib/* to work. Though we may >>> eventually want to setup the server.jar to use a classpath into >>> repository/* and then leave the lib/* only for the core launcher and >>> bits at some point in the near future. >>> >>> This adds about ~4m to the assembly at the moment, though I've not tried >>> to reduce this much, but I'm sure it can be done to reduce foot print. >>> Some may be to simply have the GShell loader pull bits from the >>> repository and/or shading jars to only include what is really needed. >>> But I'm going to leave that for later. >>> >>> Also, we can probably also convert all of the other cli tools into >>> GShell commands too, which will further simplify the platform scripts >>> and keep things uniform, and also a wee bit easier to standardize >>> testing off too ;-) >>> >>> In the assembly I left most of the scripts as they were, except for >>> startup* and added gsh*. The gsh* scripts are the main scripty bits, >>> but they are very simple. And the new startup* scripts are simply >>> delegates to gsh to invoke the "start-server" command. >>> >>> * * * >>> >>> Anyways, enough for now... please take a look, ask questions, comment, >>> whatever. I hope we can start an easy dialog about how we can make this >>> basic style of launching and cli muck the standard for 2.1. >>> >>> Cheers, >>> >>> --jason >>> >>>
