Well, I'm not sure why you are seeing that evil NCDFE still... though I did find a wee bug in the --help/-h processing for the start-server command. Basically what you tried is not a valid option to the command, ie "start-server help" is a syntax error. Instead you probably wanted to say "start-server --help".

--jason


On Aug 27, 2007, at 8:28 PM, Prasad Kashyap wrote:

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





Reply via email to