I wanted to see how much Jason really really luvvvvvs Windows. So I
began trying GShell on that OS :-)
First, I was surprised it even had batch files to support Windows
users. Thanx Jason. You really have gone out of your way :-)... Just
kidding !
gsh.bat had a small typo. svn commit: r570296 fixes that.
Next, in the interactive mode, I tried "start-server help". It threw
the following error
> start-server help
23:02:42,030 ERROR [InteractiveConsole] Error
java.lang.NoClassDefFoundError: groovy/lang/GroovyObject
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
I'll try to debug this tomorrow morning. However, I believe GShell
will be of great use/help when we want to build a stackable server
starting from a bare-bones framework that won't even have a console.
For this we'll need plugin install capabilities in the GShell.
Go Jason, Go !
Whether you like it or not, there's a sizeable number of our users who
will be on Windows. And whether I like it or not, I or somebody will
have to try our popular features on that hated OS :-(
Cheers
Prasad
On 8/21/07, Jason Dillon <[EMAIL PROTECTED]> 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
>
>
>
>
