geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: New GShell-based Geronimo Server launcher now in server/trunk
Date Mon, 27 Aug 2007 18:16:26 GMT
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?

--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
>>
>>


Mime
View raw message