geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: New GShell-based Geronimo Server launcher now in server/trunk
Date Wed, 22 Aug 2007 06:40:33 GMT
I played around with this a little bit and really like it.

Some things I'd like to see soon:

- stop the server w/o stopping the shell
- run app clients
- run the deployers (including plugin deployer).  esp. for plugins it  
might be nice to be able to set the repo to look at as an "env var"  
in gshell  and have partial listings or artifact name completion or  
something like that.
- easy way to debug, setting the port and suspend, perhaps again with  
'env vars"
- easy way to set e.g. portOffet.  IIUC you can set them with - 
Dorg.apache.geronimo.configuration.portOffset=1 but having a way of  
leaving out the prefix would be handy.... maybe -GportOffset=1

For some reason I want to be able to type commands into the console  
where I'm looking at the server console output :-)  This might end up  
being confusing or unpleasant.... but maybe an escape character could  
switch to a command mode from "viewing the console output" mode.  Or  
maybe another way to think of this is to switch back and forth  
between the server being in the background.

I'm looking forward to this developing more features :-)

many thanks!
david jencks

On Aug 21, 2007, at 9:12 PM, Jason Dillon wrote:

> FYI, for those that still like to use java -jar... you can still do  
> that, with:
>
>     java -jar lib/boot/gshell-bootstrap.jar start-server
>
> And this will actually setup all the right java.ext.dirs and such  
> too ;-)
>
> --jason
>
>
> On Aug 21, 2007, at 2:55 PM, 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