You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason Dillon <ja...@planet57.com> on 2007/08/21 23:55:46 UTC
New GShell-based Geronimo Server launcher now in server/trunk
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
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by ja...@gmail.com.
Its easy enough to get it working in 2.0.x...
--jason
-----Original Message-----
From: Jeff Genender <jg...@apache.org>
Date: Tue, 21 Aug 2007 16:05:40
To:dev@geronimo.apache.org
Subject: Re: New GShell-based Geronimo Server launcher now in server/trunk
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
>
>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jeff Genender <jg...@apache.org>.
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
>>>
>>>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jason Dillon <ja...@planet57.com>.
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
>>
>>
GShell-based Geronimo Server launcher for 2.1?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Looks like we missed 2.0.2 :-(
How do folks feel about delivering this in 2.1?
On Aug 21, 2007, at 6:05 PM, Jeff Genender wrote:
> Oh man this is sweet...
>
> I'd *really* like to see this in 2.0.2...
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jeff Genender <jg...@apache.org>.
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
>
>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jason Dillon <ja...@planet57.com>.
On Aug 23, 2007, at 8:40 AM, Joe Bohn wrote:
> Jason,
>
> I finally got around to looking at this. It's really cool!
:-)
> This is a great way to address the environment and java opt issues
> in a more dynamic way to plugins to potentially exploit.
>
> In addition to some of the items David mentioned it would also be
> great to have some more query capabilities both in gsh and the
> start-server script. For example; the ability to list all
> environment variables, list system or geronimo properties set, list
> javaopts, list of all scripts to be run prior to the starting
> server, etc...
Sure, thats all uber simple to add.
> One curious thing I noticed was that it seemed to drag a bit when I
> terminated geronimo from the console. It might have nothing to do
> with gsh but it seemed to take a long time before the gsh showed
> the server finally terminated ... just fyi and fwiw ... may be
> nothing to do with gsh.
No, its not anything to do with gsh directly, its just that you
aren't seeing the messages on the console when the server shuts
down. I'm not really sure how to capture that stuff actually, same
problem happens with the geronimo:start-sever goal.
I did however add a message to the console when a shutdown is
detected to let the user know what was going on.
--jason
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Joe Bohn <jo...@earthlink.net>.
Jason,
I finally got around to looking at this. It's really cool!
This is a great way to address the environment and java opt issues in a
more dynamic way to plugins to potentially exploit.
In addition to some of the items David mentioned it would also be great
to have some more query capabilities both in gsh and the start-server
script. For example; the ability to list all environment variables,
list system or geronimo properties set, list javaopts, list of all
scripts to be run prior to the starting server, etc...
One curious thing I noticed was that it seemed to drag a bit when I
terminated geronimo from the console. It might have nothing to do with
gsh but it seemed to take a long time before the gsh showed the server
finally terminated ... just fyi and fwiw ... may be nothing to do with gsh.
Great work Jason!
Joe
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
>
>
>
>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jeff Genender <jg...@apache.org>.
Cool stuff. I probably should have alerted you to the 2.0 version of
Mina has bugs up the wazoo and would have advocated not to use it. I
also back ported to 1.1.2 for the AyncHttpClient stuff, and that
stabilized everything.
Jeff
Jason Dillon wrote:
> Well... me thinks I've finally gotten over the major hump...
>
> I had been using Mina 2.x (which is in pre-release right now)... I was
> using it because it has some synchronous request/response handling muck
> already there which I kinda needed to implement the remote shell proxy
> muck. And well, I must have spent like a week digging through code,
> running tests, rebuilding my tree, and really... going crazy because no
> matter what I did nothing seemed to behave itself as I needed it to.
>
> So I ported and basically re-wrote all that request/response stuff I
> wanted so I could add debug to it and understand why it was not happy...
> or try to at least. It really seemed like there was some kind of
> threading problem or a sync problem but all of the diag I got from logs
> just made no sense and the results I get from running tests were random
> at best.
>
> Ugh... so anyways, I wanted to use Mina 2.0 for the request/response
> stuff... which I rewrote anyways... so a little before midnight on the
> night before the 20th I decided to move Mina 1.1.2 (latest official
> release). Updated some apis, hacked around a few other bits... and
> about 10 or 10 minutes into the 20th I had the tcp transports all ported
> and... um working!!! for the normally async, req/resp and for the stream
> i/o all at the same time. It was a nice birthday present... such a good
> feeling to finally get this crap working after going mad over it over
> the past few days!!! :-)
>
> And now over the days past I've fixed up the vm:// transport and fixed
> some bugs in the req/resp handling which were causing things to puke up
> insanity in a oh so blissful random form.
>
> Um... ya, so I think I've finally mastered... er well, beaten to
> submission, mina... which I still really like a lot btw... And I've
> implemented some framework to make using it a little easier for me,
> probably going to invent some more as I go... but right now... um... it
> seems to work. Tcp, ssl, vm... all working happy, happy. Message
> passing along side of stream i/o sitting on top of a few
> request/response bits to boot.
>
> Oh ya... and well, you can actually get a remote shell with this stuff
> now. Its not 100% functional, but you can connect to a remote server
> (running a rsh-server command), authenticate (internally it will do some
> rsa key exchange muck too) and then well, you are running commands on
> the remote system. And the output comes back to you, and you can 'exit'
> the remote shell and get back to your local shell. Wee.
>
> Its still not done though, all this batting with mina had kept me from
> finishing up the gshell rsh protocl bits and finishing up the state
> management and such... but I think I'm past that now, so I really hope
> to get these loose ends tied up soonish. Its still a bit POC, I'm still
> learning and adapting to how best to implement this stuff, but I expect
> the first version to be a "just make it work" and then after that a bit
> of refactor to clean things up (which really has how most of the gshell
> implementation has been going... sans the first week of insane code
> drops when I wrote most of it).
>
> * * *
>
> Okay, I'll stop babbling now... my point is... the remoting crapo
> works... and I think that maybe in another week or so there should be
> something functional enough for me to integration back into Geronimo.
> Something like a gsh rsh into a running server (over ssl with
> authentication) and then maybe a few stupid commands to show vm stats,
> shutdown or something else. I guess since some peeps are keen for
> scripting muck I can show how you can use the script command to execute
> a script on a server too ;-)
>
> I'm still working on the 'makecoffee --now' command...
>
> :-P
>
> Oh, and lastly... and then ya... I'll shut up... If anyone is even
> remotely interested in any of this crap it would be nice to have another
> mass of grey matter pondering over some of its present and future...
>
> Cheers,
>
> --jason
>
>
> PS. Sorry, I couldn't resist... I think that the stuff in there now
> can probably support a telnet as well as ssh transport impl too. Though
> I've yet to find an ASL friendly java ssh client+server library to build
> it with...
>
>
>
> On Sep 18, 2007, at 3:09 PM, Jason Dillon wrote:
>
>> Hiya folks... just a quick update on GShell muck...
>>
>> I've been madly hacking on the remote shell support for the past week
>> and well, its really close to being functional. I initially was going
>> to implement a POC over ActiveMQ but that was pissing me off soo much
>> that I decided to peek at what Jeff had done with GShell and
>> discovered how incredibly cool Apache Mina is!! So I've based the
>> remote-shell client/server bits off of Mina and its working out fairly
>> well, though I had to go and learn about it (which was actually
>> fun-ish, sorta, okay not really so much :-P ).
>>
>> Anyways, I've dug through GCache (which really did help me to
>> understand Mina) as well as some other Mina-based projects and I've
>> whipped up a fairly simple system (er I think so), which is extensible
>> supports TCP, SSL and VM (er well almost VM), so you can do something
>> like:
>>
>> ./bin/gsh rsh ssl://someserver:9999
>>
>> or
>>
>> ./bin/gsh rsh tcp://someserver:9999
>>
>> The same is true for the server side, to be able to accept these rsh
>> commands you could:
>>
>> ./bin/gsh rsh-server ssl://localhost:9999
>>
>> or
>>
>> ./bin/gsh rsh-server tcp://localhost:9999
>>
>> etc...
>>
>> I've implemented a RSA-based client-server handshake (similar to what
>> gcache was doing, actually based on what it was doing) to support a
>> decent authentication mechanism. Might eventually hook up some JAAS
>> crapo later, but... ya later.
>>
>> Anyways, right now I'm trying to figure out some small problems with
>> the stream message passing and marshaling, which I hope to get
>> resolved really damn soon, cause this is fricken annoying me. And
>> once that is sorted, a few minor clean up things and the
>> rsh/rsh-server bits should be functional enough to actually use.
>>
>> More to come...
>>
>> Cheers,
>>
>> --jason
>>
>>
>>
>> On Sep 8, 2007, at 12:40 PM, Jason Dillon wrote:
>>
>>> A little bit more insight into what I'm thinking of doing... since
>>> some of you can't read minds to well :-P
>>>
>>> I'd like to convert all of the assemblies to basically look like what
>>> the assemblies/geronimo-jetty6-javaee5-gshell produces.
>>>
>>> And then I'd like to start converting the other cli bits to gshell
>>> command impls, like: deployer, client and shutdown.
>>>
>>> And then (maybe around the same time or before the above), I'd like
>>> to adapt the gshell of target jvm bits to load jars from the
>>> repository, instead of using the lib/* bits.
>>>
>>> A little background for those who haven't looked at
>>> assemblies/geronimo-jetty6-javaee5-gshell and what it produces from a
>>> lib/* perspective. Right now I've set up the assembly to produce:
>>>
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell
>>>
>>> Where the bits in lib/* and lib/endorsed/* are the same as they were
>>> before. The bits in lib/boot/* and lib/gshell/* are specific to
>>> gshell. And normally a gshell installation would have everything I
>>> put into lib/gshell/* into lib/*, but I moved them to a sub dir for
>>> now... since the bin/*.jar's load jars from the ../lib/* dirs.
>>>
>>> The lib/boot/* stuff is the very minimal gshell bootstrap classes,
>>> which setup up the other happiness... and let you do things like:
>>>
>>> java -jar
>>> ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/gshell-bootstrap.jar
>>>
>>>
>>> And that will give you a nice shell... or
>>>
>>> java -jar
>>> ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/gshell-bootstrap.jar
>>> start-server
>>>
>>> That will launch the G server process using all of the right
>>> -Djava.ext.dirs and whatever properties that we currently have hacked
>>> into platform scripts.
>>>
>>> Anyways, so the idea is to move all of the bits which are current in
>>> the lib/* into the repository, and then configure the gshell command
>>> impl to load put the correct dependency artifacts onto the classpath
>>> of the target jvm that is booted up. This will augment the existing
>>> kernel bootstrap from repo stuff, putting evertying except what is
>>> needed from gshell into the repository...
>>>
>>> And really, what I'd like to eventually get to is having the
>>> bootstrap from the repository... so that everything except for what
>>> is now it lib/boot/* and lib/endorsed/* can live in the repository
>>> like happy little communistic jars should be :-P
>>>
>>> * * *
>>>
>>> And then there are longer term things for GShell...
>>>
>>> Remote administration (via, telnet, ssh, or custom ssl protocol...
>>> last is most likely to actually happen soonish)
>>>
>>> Process management, which is great for clusters, or staging ->
>>> production management. A full suite of command-line tools which can
>>> manage the configuration of a server... easily. So, for example,
>>> lets say you've got a configuration that is working really well for
>>> you... but you want to play with something new...
>>>
>>> So you might:
>>>
>>> ./bin/gsh backup-configuration before-mucking
>>> ./bin/gsh start-server
>>>
>>> And then go and change a whole bunch of stuff... and it doesn't
>>> work... yikes... so rollback...
>>>
>>> ./bin/gsh backup-configuration hosed-server
>>> ./bin/gsh restore-configuration before-mucking
>>> ./bin/gsh start-server
>>>
>>> And then maybe you want to play with the "hosed-server" configuration
>>> again...
>>>
>>> ./bin/gsh start-server --configuration hosed-server
>>>
>>> Of course, all of these could have been run from a single ./bin/gsh,
>>> but just for clarity, you can run them one off too.
>>>
>>> Maybe list or mange the configurations
>>>
>>> ./bin/gsh list-configurations
>>> ./bin/gsh remove-configuration some-unwanted-config
>>> ./bin/gsh copy-configuration default some-new-config
>>>
>>> The sky is the limit really... for what kind of management we can do...
>>>
>>> Lets say you wanted to do the above on a remote node?
>>>
>>> ./bin/gsh remote-shell someserver:9443
>>> Connecting to someserver:9447...
>>> Connected
>>>
>>> username: system
>>> password: **** (remember this is all jline, so we can mask
>>> passwords like one woudl expect)
>>>
>>> someserver:9447 > list-configurations
>>> someserver:9447 > remove-configuration some-unwanted-config
>>> someserver:9447 > copy-configuration default some-new-config
>>>
>>> So, all of these operations would happen on the node named
>>> "someserver" listening on 9443 (over ssl of course). Or how about
>>> you want to reboot a server remotely?
>>>
>>> someserver:9447 > restart-server now
>>> Geronimo server shutting down...
>>> ....
>>> Geronimo server shutdown.
>>> Geronimo server starting...
>>> ...
>>> Geronimo server started in ...
>>>
>>> Since GShell manages the processes its really easy to perform a full
>>> restart of a Server w/o needing magical platform scripting muck. And
>>> it will just work the same on each platform too.
>>>
>>> Once we have clustering, then we can do the same kinda thing for an
>>> entire cluster of nodes...
>>>
>>> someserver:9447 > restart-cluster now
>>> Shutting down 2 nodes...
>>> <node1> Geronimo server shutting down...
>>> <node1>....
>>> <node2> Geronimo server shutting down...
>>> <node2>....
>>> <node1>Geronimo server shutdown.
>>> <node2>Geronimo server shutdown.
>>> Starting up 2 nodes...
>>> <node1>Geronimo server starting...
>>> <node1>..
>>> <node2>Geronimo server starting...
>>> <node2>..
>>> <node1>Geronimo server started in ...
>>> <node2>Geronimo server started in ...
>>> Started up 2 nodes.
>>>
>>> And well, if you had some kinda script file which controlled say a
>>> logical grouping of nodes you could easily invoke that script (ya
>>> even on a remote system) and it will go and do it:
>>>
>>> someserver:9447 > script -l groovy
>>> local:file://restart-universe.groovy qa-universe
>>>
>>> The local: bit of the uri siginals the local URL handler to be used,
>>> which will cause the file://restart-universe.groovy to be loaded from
>>> the gsh instance where you are actually logged into (and ran the
>>> remote-shell gshell command) and will pipe its contents securely to
>>> the remote shell running on someserver:9447 and pass it to the script
>>> command to execute.
>>>
>>> The restart-universe.groovy might look something like this:
>>>
>>> <snip>
>>> import universe.Lookup
>>>
>>> assert args.size == 1 : 'Missing universe name'
>>>
>>> def universe = args[0]
>>>
>>> // Look up a list of nodes (for now say they are basically
>>> hostname:port)
>>> def nodes = Lookup.lookup(universe)
>>>
>>> log.info("Stopping universe ${universe}...")
>>> nodes.each { host ->
>>> shell.execute("remove-shell $host stop-server")
>>> }
>>> log.info("Universe ${universe} stopped")
>>>
>>> log.info("Starting universe ${universe}...")
>>> nodes.each { host ->
>>> shell.execute("remove-shell $host start-server")
>>> }
>>> log.info("Universe ${universe} started")
>>> </snip>
>>>
>>> Its kinda crude script, but I think you get the general point...
>>>
>>> * * *
>>>
>>> Anyways... I see... well, *HUGE* potential for this stuff...
>>>
>>> And really, a lot of what I just described above isn't that far into
>>> fantasy, its all relatively easy to implement on top of GShell... as
>>> it is now (or really as it was a year+ ago when I wrote it). Its
>>> really a matter of do others see the same value... and do others see
>>> the vision of using GShell as the core process launcher to allow
>>> things like "restart-server", or a "stop-server; copy-configuration
>>> default known-good; copy-configuration default testing;
>>> start-server", or that uber-fancy remote-shell muck.
>>>
>>> So, I'm gonna give y'all a few days to grok (or try to) what I've
>>> just spit out... please ask questions or comment, as I like to know
>>> I'm not just talking to myself here.
>>>
>>> And then maybe later next week, we might vote or come to some other
>>> consensus that this is the right direction for Geronimo, and well...
>>> then I'll make it become reality.
>>>
>>> Aighty, and now I'll shut up :-P
>>>
>>> --jason
>>>
>>>
>>>
>>> On Sep 8, 2007, at 11:53 AM, Jason Dillon wrote:
>>>
>>>> Aighty, well... I've done some long awaited re-factoring, and while
>>>> its still not _perfect_ its a whole lot better now IMO I think from
>>>> a framework perspective that its probably mature enough to take on
>>>> the task of being the server bootloader.
>>>>
>>>> I'm going to continue to refactor the guts of GShell over time, of
>>>> course... but I think that what is there now is highly usable for a
>>>> simple platform independent launcher, as well as for porting over
>>>> the other cli bits we have.
>>>>
>>>> I've done a lot of work in the past week, incase you didn't see the
>>>> storm of scm messages... pulled out pico, plopped in plexus, pulled
>>>> out commons-logging and commons-lang, which are suck and boated (in
>>>> that order). I've gotten the basic framework and supported classes
>>>> to use GShell down to ~ 1mb (a wee bit under)... though when I
>>>> started to add the layout.xml abstraction stuff, I had to pull in
>>>> xstream which bloated her back up to ~1.4m. I may eventually fix
>>>> that... or not, cause xstream is soooo very handy for xml -> object
>>>> stuff.
>>>>
>>>> I've fallen in love with annotations... they are *ucking great.
>>>> They work really well for handling the cli option and argument muck
>>>> which most every command needs to do. And striping out the
>>>> insano-sucking commons-cli really simplified command implementations
>>>> dramatically IMO.
>>>>
>>>> Anyways... I've make a heck of a lot of progress on cleaning up the
>>>> GShell framework... and more is to come I'm sure... But for now, I
>>>> think its probably ready for use primetime as the Geronimo Server's
>>>> bootloader.
>>>>
>>>> I think this provides a some significant value...
>>>>
>>>> 1) Platform scripts become consistent and relatively simple, easy
>>>> to maintain
>>>>
>>>> 2) Everyone will now have a consist way of launching the server,
>>>> even if you like a .sh, .bat, or java -jar, then end process that is
>>>> launched will be the same for everyone.
>>>>
>>>> 3) Opens up the door for some really nice and fancy fancy
>>>> management muck (like restarting the server from the web console, or
>>>> cloning a server instance or backing up a server instance...)
>>>>
>>>> 4) Lays the ground work for future features, like cluster
>>>> management, remote administration and scripting...
>>>>
>>>> * * *
>>>>
>>>> So, I think its time to decide... are we a go or no go for GShell as
>>>> the core CLI for Geronimo thingys and even more important, are we go
>>>> or no go for using GShell to boot up the server process?
>>>>
>>>> --jason
>>>>
>>>
>>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jason Dillon <ja...@planet57.com>.
Well... me thinks I've finally gotten over the major hump...
I had been using Mina 2.x (which is in pre-release right now)... I
was using it because it has some synchronous request/response
handling muck already there which I kinda needed to implement the
remote shell proxy muck. And well, I must have spent like a week
digging through code, running tests, rebuilding my tree, and
really... going crazy because no matter what I did nothing seemed to
behave itself as I needed it to.
So I ported and basically re-wrote all that request/response stuff I
wanted so I could add debug to it and understand why it was not
happy... or try to at least. It really seemed like there was some
kind of threading problem or a sync problem but all of the diag I got
from logs just made no sense and the results I get from running tests
were random at best.
Ugh... so anyways, I wanted to use Mina 2.0 for the request/response
stuff... which I rewrote anyways... so a little before midnight on
the night before the 20th I decided to move Mina 1.1.2 (latest
official release). Updated some apis, hacked around a few other
bits... and about 10 or 10 minutes into the 20th I had the tcp
transports all ported and... um working!!! for the normally async,
req/resp and for the stream i/o all at the same time. It was a nice
birthday present... such a good feeling to finally get this crap
working after going mad over it over the past few days!!! :-)
And now over the days past I've fixed up the vm:// transport and
fixed some bugs in the req/resp handling which were causing things to
puke up insanity in a oh so blissful random form.
Um... ya, so I think I've finally mastered... er well, beaten to
submission, mina... which I still really like a lot btw... And I've
implemented some framework to make using it a little easier for me,
probably going to invent some more as I go... but right now... um...
it seems to work. Tcp, ssl, vm... all working happy, happy. Message
passing along side of stream i/o sitting on top of a few request/
response bits to boot.
Oh ya... and well, you can actually get a remote shell with this
stuff now. Its not 100% functional, but you can connect to a remote
server (running a rsh-server command), authenticate (internally it
will do some rsa key exchange muck too) and then well, you are
running commands on the remote system. And the output comes back to
you, and you can 'exit' the remote shell and get back to your local
shell. Wee.
Its still not done though, all this batting with mina had kept me
from finishing up the gshell rsh protocl bits and finishing up the
state management and such... but I think I'm past that now, so I
really hope to get these loose ends tied up soonish. Its still a bit
POC, I'm still learning and adapting to how best to implement this
stuff, but I expect the first version to be a "just make it work" and
then after that a bit of refactor to clean things up (which really
has how most of the gshell implementation has been going... sans the
first week of insane code drops when I wrote most of it).
* * *
Okay, I'll stop babbling now... my point is... the remoting crapo
works... and I think that maybe in another week or so there should be
something functional enough for me to integration back into
Geronimo. Something like a gsh rsh into a running server (over ssl
with authentication) and then maybe a few stupid commands to show vm
stats, shutdown or something else. I guess since some peeps are keen
for scripting muck I can show how you can use the script command to
execute a script on a server too ;-)
I'm still working on the 'makecoffee --now' command...
:-P
Oh, and lastly... and then ya... I'll shut up... If anyone is even
remotely interested in any of this crap it would be nice to have
another mass of grey matter pondering over some of its present and
future...
Cheers,
--jason
PS. Sorry, I couldn't resist... I think that the stuff in there now
can probably support a telnet as well as ssh transport impl too.
Though I've yet to find an ASL friendly java ssh client+server
library to build it with...
On Sep 18, 2007, at 3:09 PM, Jason Dillon wrote:
> Hiya folks... just a quick update on GShell muck...
>
> I've been madly hacking on the remote shell support for the past
> week and well, its really close to being functional. I initially
> was going to implement a POC over ActiveMQ but that was pissing me
> off soo much that I decided to peek at what Jeff had done with
> GShell and discovered how incredibly cool Apache Mina is!! So I've
> based the remote-shell client/server bits off of Mina and its
> working out fairly well, though I had to go and learn about it
> (which was actually fun-ish, sorta, okay not really so much :-P ).
>
> Anyways, I've dug through GCache (which really did help me to
> understand Mina) as well as some other Mina-based projects and I've
> whipped up a fairly simple system (er I think so), which is
> extensible supports TCP, SSL and VM (er well almost VM), so you can
> do something like:
>
> ./bin/gsh rsh ssl://someserver:9999
>
> or
>
> ./bin/gsh rsh tcp://someserver:9999
>
> The same is true for the server side, to be able to accept these
> rsh commands you could:
>
> ./bin/gsh rsh-server ssl://localhost:9999
>
> or
>
> ./bin/gsh rsh-server tcp://localhost:9999
>
> etc...
>
> I've implemented a RSA-based client-server handshake (similar to
> what gcache was doing, actually based on what it was doing) to
> support a decent authentication mechanism. Might eventually hook
> up some JAAS crapo later, but... ya later.
>
> Anyways, right now I'm trying to figure out some small problems
> with the stream message passing and marshaling, which I hope to get
> resolved really damn soon, cause this is fricken annoying me. And
> once that is sorted, a few minor clean up things and the rsh/rsh-
> server bits should be functional enough to actually use.
>
> More to come...
>
> Cheers,
>
> --jason
>
>
>
> On Sep 8, 2007, at 12:40 PM, Jason Dillon wrote:
>
>> A little bit more insight into what I'm thinking of doing... since
>> some of you can't read minds to well :-P
>>
>> I'd like to convert all of the assemblies to basically look like
>> what the assemblies/geronimo-jetty6-javaee5-gshell produces.
>>
>> And then I'd like to start converting the other cli bits to gshell
>> command impls, like: deployer, client and shutdown.
>>
>> And then (maybe around the same time or before the above), I'd
>> like to adapt the gshell of target jvm bits to load jars from the
>> repository, instead of using the lib/* bits.
>>
>> A little background for those who haven't looked at assemblies/
>> geronimo-jetty6-javaee5-gshell and what it produces from a lib/*
>> perspective. Right now I've set up the assembly to produce:
>>
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell
>>
>> Where the bits in lib/* and lib/endorsed/* are the same as they
>> were before. The bits in lib/boot/* and lib/gshell/* are specific
>> to gshell. And normally a gshell installation would have
>> everything I put into lib/gshell/* into lib/*, but I moved them to
>> a sub dir for now... since the bin/*.jar's load jars from the ../
>> lib/* dirs.
>>
>> The lib/boot/* stuff is the very minimal gshell bootstrap classes,
>> which setup up the other happiness... and let you do things like:
>>
>> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
>> boot/gshell-bootstrap.jar
>>
>> And that will give you a nice shell... or
>>
>> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
>> boot/gshell-bootstrap.jar start-server
>>
>> That will launch the G server process using all of the right -
>> Djava.ext.dirs and whatever properties that we currently have
>> hacked into platform scripts.
>>
>> Anyways, so the idea is to move all of the bits which are current
>> in the lib/* into the repository, and then configure the gshell
>> command impl to load put the correct dependency artifacts onto the
>> classpath of the target jvm that is booted up. This will augment
>> the existing kernel bootstrap from repo stuff, putting evertying
>> except what is needed from gshell into the repository...
>>
>> And really, what I'd like to eventually get to is having the
>> bootstrap from the repository... so that everything except for
>> what is now it lib/boot/* and lib/endorsed/* can live in the
>> repository like happy little communistic jars should be :-P
>>
>> * * *
>>
>> And then there are longer term things for GShell...
>>
>> Remote administration (via, telnet, ssh, or custom ssl protocol...
>> last is most likely to actually happen soonish)
>>
>> Process management, which is great for clusters, or staging ->
>> production management. A full suite of command-line tools which
>> can manage the configuration of a server... easily. So, for
>> example, lets say you've got a configuration that is working
>> really well for you... but you want to play with something new...
>>
>> So you might:
>>
>> ./bin/gsh backup-configuration before-mucking
>> ./bin/gsh start-server
>>
>> And then go and change a whole bunch of stuff... and it doesn't
>> work... yikes... so rollback...
>>
>> ./bin/gsh backup-configuration hosed-server
>> ./bin/gsh restore-configuration before-mucking
>> ./bin/gsh start-server
>>
>> And then maybe you want to play with the "hosed-server"
>> configuration again...
>>
>> ./bin/gsh start-server --configuration hosed-server
>>
>> Of course, all of these could have been run from a single ./bin/
>> gsh, but just for clarity, you can run them one off too.
>>
>> Maybe list or mange the configurations
>>
>> ./bin/gsh list-configurations
>> ./bin/gsh remove-configuration some-unwanted-config
>> ./bin/gsh copy-configuration default some-new-config
>>
>> The sky is the limit really... for what kind of management we can
>> do...
>>
>> Lets say you wanted to do the above on a remote node?
>>
>> ./bin/gsh remote-shell someserver:9443
>> Connecting to someserver:9447...
>> Connected
>>
>> username: system
>> password: **** (remember this is all jline, so we can mask
>> passwords like one woudl expect)
>>
>> someserver:9447 > list-configurations
>> someserver:9447 > remove-configuration some-unwanted-config
>> someserver:9447 > copy-configuration default some-new-config
>>
>> So, all of these operations would happen on the node named
>> "someserver" listening on 9443 (over ssl of course). Or how about
>> you want to reboot a server remotely?
>>
>> someserver:9447 > restart-server now
>> Geronimo server shutting down...
>> ....
>> Geronimo server shutdown.
>> Geronimo server starting...
>> ...
>> Geronimo server started in ...
>>
>> Since GShell manages the processes its really easy to perform a
>> full restart of a Server w/o needing magical platform scripting
>> muck. And it will just work the same on each platform too.
>>
>> Once we have clustering, then we can do the same kinda thing for
>> an entire cluster of nodes...
>>
>> someserver:9447 > restart-cluster now
>> Shutting down 2 nodes...
>> <node1> Geronimo server shutting down...
>> <node1>....
>> <node2> Geronimo server shutting down...
>> <node2>....
>> <node1>Geronimo server shutdown.
>> <node2>Geronimo server shutdown.
>> Starting up 2 nodes...
>> <node1>Geronimo server starting...
>> <node1>..
>> <node2>Geronimo server starting...
>> <node2>..
>> <node1>Geronimo server started in ...
>> <node2>Geronimo server started in ...
>> Started up 2 nodes.
>>
>> And well, if you had some kinda script file which controlled say a
>> logical grouping of nodes you could easily invoke that script (ya
>> even on a remote system) and it will go and do it:
>>
>> someserver:9447 > script -l groovy local:file://restart-
>> universe.groovy qa-universe
>>
>> The local: bit of the uri siginals the local URL handler to be
>> used, which will cause the file://restart-universe.groovy to be
>> loaded from the gsh instance where you are actually logged into
>> (and ran the remote-shell gshell command) and will pipe its
>> contents securely to the remote shell running on someserver:9447
>> and pass it to the script command to execute.
>>
>> The restart-universe.groovy might look something like this:
>>
>> <snip>
>> import universe.Lookup
>>
>> assert args.size == 1 : 'Missing universe name'
>>
>> def universe = args[0]
>>
>> // Look up a list of nodes (for now say they are basically
>> hostname:port)
>> def nodes = Lookup.lookup(universe)
>>
>> log.info("Stopping universe ${universe}...")
>> nodes.each { host ->
>> shell.execute("remove-shell $host stop-server")
>> }
>> log.info("Universe ${universe} stopped")
>>
>> log.info("Starting universe ${universe}...")
>> nodes.each { host ->
>> shell.execute("remove-shell $host start-server")
>> }
>> log.info("Universe ${universe} started")
>> </snip>
>>
>> Its kinda crude script, but I think you get the general point...
>>
>> * * *
>>
>> Anyways... I see... well, *HUGE* potential for this stuff...
>>
>> And really, a lot of what I just described above isn't that far
>> into fantasy, its all relatively easy to implement on top of
>> GShell... as it is now (or really as it was a year+ ago when I
>> wrote it). Its really a matter of do others see the same value...
>> and do others see the vision of using GShell as the core process
>> launcher to allow things like "restart-server", or a "stop-server;
>> copy-configuration default known-good; copy-configuration default
>> testing; start-server", or that uber-fancy remote-shell muck.
>>
>> So, I'm gonna give y'all a few days to grok (or try to) what I've
>> just spit out... please ask questions or comment, as I like to
>> know I'm not just talking to myself here.
>>
>> And then maybe later next week, we might vote or come to some
>> other consensus that this is the right direction for Geronimo, and
>> well... then I'll make it become reality.
>>
>> Aighty, and now I'll shut up :-P
>>
>> --jason
>>
>>
>>
>> On Sep 8, 2007, at 11:53 AM, Jason Dillon wrote:
>>
>>> Aighty, well... I've done some long awaited re-factoring, and
>>> while its still not _perfect_ its a whole lot better now IMO I
>>> think from a framework perspective that its probably mature
>>> enough to take on the task of being the server bootloader.
>>>
>>> I'm going to continue to refactor the guts of GShell over time,
>>> of course... but I think that what is there now is highly usable
>>> for a simple platform independent launcher, as well as for
>>> porting over the other cli bits we have.
>>>
>>> I've done a lot of work in the past week, incase you didn't see
>>> the storm of scm messages... pulled out pico, plopped in plexus,
>>> pulled out commons-logging and commons-lang, which are suck and
>>> boated (in that order). I've gotten the basic framework and
>>> supported classes to use GShell down to ~ 1mb (a wee bit
>>> under)... though when I started to add the layout.xml abstraction
>>> stuff, I had to pull in xstream which bloated her back up to
>>> ~1.4m. I may eventually fix that... or not, cause xstream is
>>> soooo very handy for xml -> object stuff.
>>>
>>> I've fallen in love with annotations... they are *ucking great.
>>> They work really well for handling the cli option and argument
>>> muck which most every command needs to do. And striping out the
>>> insano-sucking commons-cli really simplified command
>>> implementations dramatically IMO.
>>>
>>> Anyways... I've make a heck of a lot of progress on cleaning up
>>> the GShell framework... and more is to come I'm sure... But for
>>> now, I think its probably ready for use primetime as the Geronimo
>>> Server's bootloader.
>>>
>>> I think this provides a some significant value...
>>>
>>> 1) Platform scripts become consistent and relatively simple,
>>> easy to maintain
>>>
>>> 2) Everyone will now have a consist way of launching the server,
>>> even if you like a .sh, .bat, or java -jar, then end process that
>>> is launched will be the same for everyone.
>>>
>>> 3) Opens up the door for some really nice and fancy fancy
>>> management muck (like restarting the server from the web console,
>>> or cloning a server instance or backing up a server instance...)
>>>
>>> 4) Lays the ground work for future features, like cluster
>>> management, remote administration and scripting...
>>>
>>> * * *
>>>
>>> So, I think its time to decide... are we a go or no go for GShell
>>> as the core CLI for Geronimo thingys and even more important, are
>>> we go or no go for using GShell to boot up the server process?
>>>
>>> --jason
>>>
>>
>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jason Dillon <ja...@planet57.com>.
Hiya folks... just a quick update on GShell muck...
I've been madly hacking on the remote shell support for the past week
and well, its really close to being functional. I initially was
going to implement a POC over ActiveMQ but that was pissing me off
soo much that I decided to peek at what Jeff had done with GShell and
discovered how incredibly cool Apache Mina is!! So I've based the
remote-shell client/server bits off of Mina and its working out
fairly well, though I had to go and learn about it (which was
actually fun-ish, sorta, okay not really so much :-P ).
Anyways, I've dug through GCache (which really did help me to
understand Mina) as well as some other Mina-based projects and I've
whipped up a fairly simple system (er I think so), which is
extensible supports TCP, SSL and VM (er well almost VM), so you can
do something like:
./bin/gsh rsh ssl://someserver:9999
or
./bin/gsh rsh tcp://someserver:9999
The same is true for the server side, to be able to accept these rsh
commands you could:
./bin/gsh rsh-server ssl://localhost:9999
or
./bin/gsh rsh-server tcp://localhost:9999
etc...
I've implemented a RSA-based client-server handshake (similar to what
gcache was doing, actually based on what it was doing) to support a
decent authentication mechanism. Might eventually hook up some JAAS
crapo later, but... ya later.
Anyways, right now I'm trying to figure out some small problems with
the stream message passing and marshaling, which I hope to get
resolved really damn soon, cause this is fricken annoying me. And
once that is sorted, a few minor clean up things and the rsh/rsh-
server bits should be functional enough to actually use.
More to come...
Cheers,
--jason
On Sep 8, 2007, at 12:40 PM, Jason Dillon wrote:
> A little bit more insight into what I'm thinking of doing... since
> some of you can't read minds to well :-P
>
> I'd like to convert all of the assemblies to basically look like
> what the assemblies/geronimo-jetty6-javaee5-gshell produces.
>
> And then I'd like to start converting the other cli bits to gshell
> command impls, like: deployer, client and shutdown.
>
> And then (maybe around the same time or before the above), I'd like
> to adapt the gshell of target jvm bits to load jars from the
> repository, instead of using the lib/* bits.
>
> A little background for those who haven't looked at assemblies/
> geronimo-jetty6-javaee5-gshell and what it produces from a lib/*
> perspective. Right now I've set up the assembly to produce:
>
> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib
> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot
> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed
> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell
>
> Where the bits in lib/* and lib/endorsed/* are the same as they
> were before. The bits in lib/boot/* and lib/gshell/* are specific
> to gshell. And normally a gshell installation would have
> everything I put into lib/gshell/* into lib/*, but I moved them to
> a sub dir for now... since the bin/*.jar's load jars from the ../
> lib/* dirs.
>
> The lib/boot/* stuff is the very minimal gshell bootstrap classes,
> which setup up the other happiness... and let you do things like:
>
> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
> boot/gshell-bootstrap.jar
>
> And that will give you a nice shell... or
>
> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
> boot/gshell-bootstrap.jar start-server
>
> That will launch the G server process using all of the right -
> Djava.ext.dirs and whatever properties that we currently have
> hacked into platform scripts.
>
> Anyways, so the idea is to move all of the bits which are current
> in the lib/* into the repository, and then configure the gshell
> command impl to load put the correct dependency artifacts onto the
> classpath of the target jvm that is booted up. This will augment
> the existing kernel bootstrap from repo stuff, putting evertying
> except what is needed from gshell into the repository...
>
> And really, what I'd like to eventually get to is having the
> bootstrap from the repository... so that everything except for what
> is now it lib/boot/* and lib/endorsed/* can live in the repository
> like happy little communistic jars should be :-P
>
> * * *
>
> And then there are longer term things for GShell...
>
> Remote administration (via, telnet, ssh, or custom ssl protocol...
> last is most likely to actually happen soonish)
>
> Process management, which is great for clusters, or staging ->
> production management. A full suite of command-line tools which
> can manage the configuration of a server... easily. So, for
> example, lets say you've got a configuration that is working really
> well for you... but you want to play with something new...
>
> So you might:
>
> ./bin/gsh backup-configuration before-mucking
> ./bin/gsh start-server
>
> And then go and change a whole bunch of stuff... and it doesn't
> work... yikes... so rollback...
>
> ./bin/gsh backup-configuration hosed-server
> ./bin/gsh restore-configuration before-mucking
> ./bin/gsh start-server
>
> And then maybe you want to play with the "hosed-server"
> configuration again...
>
> ./bin/gsh start-server --configuration hosed-server
>
> Of course, all of these could have been run from a single ./bin/
> gsh, but just for clarity, you can run them one off too.
>
> Maybe list or mange the configurations
>
> ./bin/gsh list-configurations
> ./bin/gsh remove-configuration some-unwanted-config
> ./bin/gsh copy-configuration default some-new-config
>
> The sky is the limit really... for what kind of management we can
> do...
>
> Lets say you wanted to do the above on a remote node?
>
> ./bin/gsh remote-shell someserver:9443
> Connecting to someserver:9447...
> Connected
>
> username: system
> password: **** (remember this is all jline, so we can mask
> passwords like one woudl expect)
>
> someserver:9447 > list-configurations
> someserver:9447 > remove-configuration some-unwanted-config
> someserver:9447 > copy-configuration default some-new-config
>
> So, all of these operations would happen on the node named
> "someserver" listening on 9443 (over ssl of course). Or how about
> you want to reboot a server remotely?
>
> someserver:9447 > restart-server now
> Geronimo server shutting down...
> ....
> Geronimo server shutdown.
> Geronimo server starting...
> ...
> Geronimo server started in ...
>
> Since GShell manages the processes its really easy to perform a
> full restart of a Server w/o needing magical platform scripting
> muck. And it will just work the same on each platform too.
>
> Once we have clustering, then we can do the same kinda thing for an
> entire cluster of nodes...
>
> someserver:9447 > restart-cluster now
> Shutting down 2 nodes...
> <node1> Geronimo server shutting down...
> <node1>....
> <node2> Geronimo server shutting down...
> <node2>....
> <node1>Geronimo server shutdown.
> <node2>Geronimo server shutdown.
> Starting up 2 nodes...
> <node1>Geronimo server starting...
> <node1>..
> <node2>Geronimo server starting...
> <node2>..
> <node1>Geronimo server started in ...
> <node2>Geronimo server started in ...
> Started up 2 nodes.
>
> And well, if you had some kinda script file which controlled say a
> logical grouping of nodes you could easily invoke that script (ya
> even on a remote system) and it will go and do it:
>
> someserver:9447 > script -l groovy local:file://restart-
> universe.groovy qa-universe
>
> The local: bit of the uri siginals the local URL handler to be
> used, which will cause the file://restart-universe.groovy to be
> loaded from the gsh instance where you are actually logged into
> (and ran the remote-shell gshell command) and will pipe its
> contents securely to the remote shell running on someserver:9447
> and pass it to the script command to execute.
>
> The restart-universe.groovy might look something like this:
>
> <snip>
> import universe.Lookup
>
> assert args.size == 1 : 'Missing universe name'
>
> def universe = args[0]
>
> // Look up a list of nodes (for now say they are basically
> hostname:port)
> def nodes = Lookup.lookup(universe)
>
> log.info("Stopping universe ${universe}...")
> nodes.each { host ->
> shell.execute("remove-shell $host stop-server")
> }
> log.info("Universe ${universe} stopped")
>
> log.info("Starting universe ${universe}...")
> nodes.each { host ->
> shell.execute("remove-shell $host start-server")
> }
> log.info("Universe ${universe} started")
> </snip>
>
> Its kinda crude script, but I think you get the general point...
>
> * * *
>
> Anyways... I see... well, *HUGE* potential for this stuff...
>
> And really, a lot of what I just described above isn't that far
> into fantasy, its all relatively easy to implement on top of
> GShell... as it is now (or really as it was a year+ ago when I
> wrote it). Its really a matter of do others see the same value...
> and do others see the vision of using GShell as the core process
> launcher to allow things like "restart-server", or a "stop-server;
> copy-configuration default known-good; copy-configuration default
> testing; start-server", or that uber-fancy remote-shell muck.
>
> So, I'm gonna give y'all a few days to grok (or try to) what I've
> just spit out... please ask questions or comment, as I like to know
> I'm not just talking to myself here.
>
> And then maybe later next week, we might vote or come to some other
> consensus that this is the right direction for Geronimo, and
> well... then I'll make it become reality.
>
> Aighty, and now I'll shut up :-P
>
> --jason
>
>
>
> On Sep 8, 2007, at 11:53 AM, Jason Dillon wrote:
>
>> Aighty, well... I've done some long awaited re-factoring, and
>> while its still not _perfect_ its a whole lot better now IMO I
>> think from a framework perspective that its probably mature enough
>> to take on the task of being the server bootloader.
>>
>> I'm going to continue to refactor the guts of GShell over time, of
>> course... but I think that what is there now is highly usable for
>> a simple platform independent launcher, as well as for porting
>> over the other cli bits we have.
>>
>> I've done a lot of work in the past week, incase you didn't see
>> the storm of scm messages... pulled out pico, plopped in plexus,
>> pulled out commons-logging and commons-lang, which are suck and
>> boated (in that order). I've gotten the basic framework and
>> supported classes to use GShell down to ~ 1mb (a wee bit under)...
>> though when I started to add the layout.xml abstraction stuff, I
>> had to pull in xstream which bloated her back up to ~1.4m. I may
>> eventually fix that... or not, cause xstream is soooo very handy
>> for xml -> object stuff.
>>
>> I've fallen in love with annotations... they are *ucking great.
>> They work really well for handling the cli option and argument
>> muck which most every command needs to do. And striping out the
>> insano-sucking commons-cli really simplified command
>> implementations dramatically IMO.
>>
>> Anyways... I've make a heck of a lot of progress on cleaning up
>> the GShell framework... and more is to come I'm sure... But for
>> now, I think its probably ready for use primetime as the Geronimo
>> Server's bootloader.
>>
>> I think this provides a some significant value...
>>
>> 1) Platform scripts become consistent and relatively simple, easy
>> to maintain
>>
>> 2) Everyone will now have a consist way of launching the server,
>> even if you like a .sh, .bat, or java -jar, then end process that
>> is launched will be the same for everyone.
>>
>> 3) Opens up the door for some really nice and fancy fancy
>> management muck (like restarting the server from the web console,
>> or cloning a server instance or backing up a server instance...)
>>
>> 4) Lays the ground work for future features, like cluster
>> management, remote administration and scripting...
>>
>> * * *
>>
>> So, I think its time to decide... are we a go or no go for GShell
>> as the core CLI for Geronimo thingys and even more important, are
>> we go or no go for using GShell to boot up the server process?
>>
>> --jason
>>
>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by David Jencks <da...@yahoo.com>.
On Sep 8, 2007, at 1:46 PM, Jason Dillon wrote:
> Ya, should be simple enough... though I don't want to keep
> maintaining these extra assemblies, I'd like to just convert all of
> the assemblies to use this stuff...
I was convinced this was the way to go after trying the first jetty-
gshell a couple weeks ago.
thanks
david jencks
>
> But if it helps ya out, I can make a geronimo-tomcat6-javaee5-
> gshell...
>
> --jason
>
>
> On Sep 8, 2007, at 12:52 PM, Jeff Genender wrote:
>
>> Is this working for the Tomcat assembly? If not...can it soon?
>>
>> Thanks,
>>
>> Jeff
>> Sent from my iPhone
>>
>> On Sep 8, 2007, at 1:40 PM, Jason Dillon <ja...@planet57.com> wrote:
>>
>>> A little bit more insight into what I'm thinking of doing...
>>> since some of you can't read minds to well :-P
>>>
>>> I'd like to convert all of the assemblies to basically look like
>>> what the assemblies/geronimo-jetty6-javaee5-gshell produces.
>>>
>>> And then I'd like to start converting the other cli bits to
>>> gshell command impls, like: deployer, client and shutdown.
>>>
>>> And then (maybe around the same time or before the above), I'd
>>> like to adapt the gshell of target jvm bits to load jars from the
>>> repository, instead of using the lib/* bits.
>>>
>>> A little background for those who haven't looked at assemblies/
>>> geronimo-jetty6-javaee5-gshell and what it produces from a lib/*
>>> perspective. Right now I've set up the assembly to produce:
>>>
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell
>>>
>>> Where the bits in lib/* and lib/endorsed/* are the same as they
>>> were before. The bits in lib/boot/* and lib/gshell/* are
>>> specific to gshell. And normally a gshell installation would
>>> have everything I put into lib/gshell/* into lib/*, but I moved
>>> them to a sub dir for now... since the bin/*.jar's load jars from
>>> the ../lib/* dirs.
>>>
>>> The lib/boot/* stuff is the very minimal gshell bootstrap
>>> classes, which setup up the other happiness... and let you do
>>> things like:
>>>
>>> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
>>> boot/gshell-bootstrap.jar
>>>
>>> And that will give you a nice shell... or
>>>
>>> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
>>> boot/gshell-bootstrap.jar start-server
>>>
>>> That will launch the G server process using all of the right -
>>> Djava.ext.dirs and whatever properties that we currently have
>>> hacked into platform scripts.
>>>
>>> Anyways, so the idea is to move all of the bits which are current
>>> in the lib/* into the repository, and then configure the gshell
>>> command impl to load put the correct dependency artifacts onto
>>> the classpath of the target jvm that is booted up. This will
>>> augment the existing kernel bootstrap from repo stuff, putting
>>> evertying except what is needed from gshell into the repository...
>>>
>>> And really, what I'd like to eventually get to is having the
>>> bootstrap from the repository... so that everything except for
>>> what is now it lib/boot/* and lib/endorsed/* can live in the
>>> repository like happy little communistic jars should be :-P
>>>
>>> * * *
>>>
>>> And then there are longer term things for GShell...
>>>
>>> Remote administration (via, telnet, ssh, or custom ssl
>>> protocol... last is most likely to actually happen soonish)
>>>
>>> Process management, which is great for clusters, or staging ->
>>> production management. A full suite of command-line tools which
>>> can manage the configuration of a server... easily. So, for
>>> example, lets say you've got a configuration that is working
>>> really well for you... but you want to play with something new...
>>>
>>> So you might:
>>>
>>> ./bin/gsh backup-configuration before-mucking
>>> ./bin/gsh start-server
>>>
>>> And then go and change a whole bunch of stuff... and it doesn't
>>> work... yikes... so rollback...
>>>
>>> ./bin/gsh backup-configuration hosed-server
>>> ./bin/gsh restore-configuration before-mucking
>>> ./bin/gsh start-server
>>>
>>> And then maybe you want to play with the "hosed-server"
>>> configuration again...
>>>
>>> ./bin/gsh start-server --configuration hosed-server
>>>
>>> Of course, all of these could have been run from a single ./bin/
>>> gsh, but just for clarity, you can run them one off too.
>>>
>>> Maybe list or mange the configurations
>>>
>>> ./bin/gsh list-configurations
>>> ./bin/gsh remove-configuration some-unwanted-config
>>> ./bin/gsh copy-configuration default some-new-config
>>>
>>> The sky is the limit really... for what kind of management we can
>>> do...
>>>
>>> Lets say you wanted to do the above on a remote node?
>>>
>>> ./bin/gsh remote-shell someserver:9443
>>> Connecting to someserver:9447...
>>> Connected
>>>
>>> username: system
>>> password: **** (remember this is all jline, so we can mask
>>> passwords like one woudl expect)
>>>
>>> someserver:9447 > list-configurations
>>> someserver:9447 > remove-configuration some-unwanted-config
>>> someserver:9447 > copy-configuration default some-new-config
>>>
>>> So, all of these operations would happen on the node named
>>> "someserver" listening on 9443 (over ssl of course). Or how
>>> about you want to reboot a server remotely?
>>>
>>> someserver:9447 > restart-server now
>>> Geronimo server shutting down...
>>> ....
>>> Geronimo server shutdown.
>>> Geronimo server starting...
>>> ...
>>> Geronimo server started in ...
>>>
>>> Since GShell manages the processes its really easy to perform a
>>> full restart of a Server w/o needing magical platform scripting
>>> muck. And it will just work the same on each platform too.
>>>
>>> Once we have clustering, then we can do the same kinda thing for
>>> an entire cluster of nodes...
>>>
>>> someserver:9447 > restart-cluster now
>>> Shutting down 2 nodes...
>>> <node1> Geronimo server shutting down...
>>> <node1>....
>>> <node2> Geronimo server shutting down...
>>> <node2>....
>>> <node1>Geronimo server shutdown.
>>> <node2>Geronimo server shutdown.
>>> Starting up 2 nodes...
>>> <node1>Geronimo server starting...
>>> <node1>..
>>> <node2>Geronimo server starting...
>>> <node2>..
>>> <node1>Geronimo server started in ...
>>> <node2>Geronimo server started in ...
>>> Started up 2 nodes.
>>>
>>> And well, if you had some kinda script file which controlled say
>>> a logical grouping of nodes you could easily invoke that script
>>> (ya even on a remote system) and it will go and do it:
>>>
>>> someserver:9447 > script -l groovy local:file://restart-
>>> universe.groovy qa-universe
>>>
>>> The local: bit of the uri siginals the local URL handler to be
>>> used, which will cause the file://restart-universe.groovy to be
>>> loaded from the gsh instance where you are actually logged into
>>> (and ran the remote-shell gshell command) and will pipe its
>>> contents securely to the remote shell running on someserver:9447
>>> and pass it to the script command to execute.
>>>
>>> The restart-universe.groovy might look something like this:
>>>
>>> <snip>
>>> import universe.Lookup
>>>
>>> assert args.size == 1 : 'Missing universe name'
>>>
>>> def universe = args[0]
>>>
>>> // Look up a list of nodes (for now say they are basically
>>> hostname:port)
>>> def nodes = Lookup.lookup(universe)
>>>
>>> log.info("Stopping universe ${universe}...")
>>> nodes.each { host ->
>>> shell.execute("remove-shell $host stop-server")
>>> }
>>> log.info("Universe ${universe} stopped")
>>>
>>> log.info("Starting universe ${universe}...")
>>> nodes.each { host ->
>>> shell.execute("remove-shell $host start-server")
>>> }
>>> log.info("Universe ${universe} started")
>>> </snip>
>>>
>>> Its kinda crude script, but I think you get the general point...
>>>
>>> * * *
>>>
>>> Anyways... I see... well, *HUGE* potential for this stuff...
>>>
>>> And really, a lot of what I just described above isn't that far
>>> into fantasy, its all relatively easy to implement on top of
>>> GShell... as it is now (or really as it was a year+ ago when I
>>> wrote it). Its really a matter of do others see the same
>>> value... and do others see the vision of using GShell as the core
>>> process launcher to allow things like "restart-server", or a
>>> "stop-server; copy-configuration default known-good; copy-
>>> configuration default testing; start-server", or that uber-fancy
>>> remote-shell muck.
>>>
>>> So, I'm gonna give y'all a few days to grok (or try to) what I've
>>> just spit out... please ask questions or comment, as I like to
>>> know I'm not just talking to myself here.
>>>
>>> And then maybe later next week, we might vote or come to some
>>> other consensus that this is the right direction for Geronimo,
>>> and well... then I'll make it become reality.
>>>
>>> Aighty, and now I'll shut up :-P
>>>
>>> --jason
>>>
>>>
>>>
>>> On Sep 8, 2007, at 11:53 AM, Jason Dillon wrote:
>>>
>>>> Aighty, well... I've done some long awaited re-factoring, and
>>>> while its still not _perfect_ its a whole lot better now IMO I
>>>> think from a framework perspective that its probably mature
>>>> enough to take on the task of being the server bootloader.
>>>>
>>>> I'm going to continue to refactor the guts of GShell over time,
>>>> of course... but I think that what is there now is highly usable
>>>> for a simple platform independent launcher, as well as for
>>>> porting over the other cli bits we have.
>>>>
>>>> I've done a lot of work in the past week, incase you didn't see
>>>> the storm of scm messages... pulled out pico, plopped in plexus,
>>>> pulled out commons-logging and commons-lang, which are suck and
>>>> boated (in that order). I've gotten the basic framework and
>>>> supported classes to use GShell down to ~ 1mb (a wee bit
>>>> under)... though when I started to add the layout.xml
>>>> abstraction stuff, I had to pull in xstream which bloated her
>>>> back up to ~1.4m. I may eventually fix that... or not, cause
>>>> xstream is soooo very handy for xml -> object stuff.
>>>>
>>>> I've fallen in love with annotations... they are *ucking great.
>>>> They work really well for handling the cli option and argument
>>>> muck which most every command needs to do. And striping out the
>>>> insano-sucking commons-cli really simplified command
>>>> implementations dramatically IMO.
>>>>
>>>> Anyways... I've make a heck of a lot of progress on cleaning up
>>>> the GShell framework... and more is to come I'm sure... But for
>>>> now, I think its probably ready for use primetime as the
>>>> Geronimo Server's bootloader.
>>>>
>>>> I think this provides a some significant value...
>>>>
>>>> 1) Platform scripts become consistent and relatively simple,
>>>> easy to maintain
>>>>
>>>> 2) Everyone will now have a consist way of launching the server,
>>>> even if you like a .sh, .bat, or java -jar, then end process
>>>> that is launched will be the same for everyone.
>>>>
>>>> 3) Opens up the door for some really nice and fancy fancy
>>>> management muck (like restarting the server from the web
>>>> console, or cloning a server instance or backing up a server
>>>> instance...)
>>>>
>>>> 4) Lays the ground work for future features, like cluster
>>>> management, remote administration and scripting...
>>>>
>>>> * * *
>>>>
>>>> So, I think its time to decide... are we a go or no go for
>>>> GShell as the core CLI for Geronimo thingys and even more
>>>> important, are we go or no go for using GShell to boot up the
>>>> server process?
>>>>
>>>> --jason
>>>>
>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jeff Genender <jg...@apache.org>.
Yeah...I need Tomcat for this plugin I am working on..thanks.
Jeff
Jason Dillon wrote:
> Ya, should be simple enough... though I don't want to keep maintaining
> these extra assemblies, I'd like to just convert all of the assemblies
> to use this stuff...
>
> But if it helps ya out, I can make a geronimo-tomcat6-javaee5-gshell...
>
> --jason
>
>
> On Sep 8, 2007, at 12:52 PM, Jeff Genender wrote:
>
>> Is this working for the Tomcat assembly? If not...can it soon?
>>
>> Thanks,
>>
>> Jeff
>> Sent from my iPhone
>>
>> On Sep 8, 2007, at 1:40 PM, Jason Dillon <ja...@planet57.com> wrote:
>>
>>> A little bit more insight into what I'm thinking of doing... since
>>> some of you can't read minds to well :-P
>>>
>>> I'd like to convert all of the assemblies to basically look like what
>>> the assemblies/geronimo-jetty6-javaee5-gshell produces.
>>>
>>> And then I'd like to start converting the other cli bits to gshell
>>> command impls, like: deployer, client and shutdown.
>>>
>>> And then (maybe around the same time or before the above), I'd like
>>> to adapt the gshell of target jvm bits to load jars from the
>>> repository, instead of using the lib/* bits.
>>>
>>> A little background for those who haven't looked at
>>> assemblies/geronimo-jetty6-javaee5-gshell and what it produces from a
>>> lib/* perspective. Right now I've set up the assembly to produce:
>>>
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell
>>>
>>> Where the bits in lib/* and lib/endorsed/* are the same as they were
>>> before. The bits in lib/boot/* and lib/gshell/* are specific to
>>> gshell. And normally a gshell installation would have everything I
>>> put into lib/gshell/* into lib/*, but I moved them to a sub dir for
>>> now... since the bin/*.jar's load jars from the ../lib/* dirs.
>>>
>>> The lib/boot/* stuff is the very minimal gshell bootstrap classes,
>>> which setup up the other happiness... and let you do things like:
>>>
>>> java -jar
>>> ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/gshell-bootstrap.jar
>>>
>>>
>>> And that will give you a nice shell... or
>>>
>>> java -jar
>>> ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/gshell-bootstrap.jar
>>> start-server
>>>
>>> That will launch the G server process using all of the right
>>> -Djava.ext.dirs and whatever properties that we currently have hacked
>>> into platform scripts.
>>>
>>> Anyways, so the idea is to move all of the bits which are current in
>>> the lib/* into the repository, and then configure the gshell command
>>> impl to load put the correct dependency artifacts onto the classpath
>>> of the target jvm that is booted up. This will augment the existing
>>> kernel bootstrap from repo stuff, putting evertying except what is
>>> needed from gshell into the repository...
>>>
>>> And really, what I'd like to eventually get to is having the
>>> bootstrap from the repository... so that everything except for what
>>> is now it lib/boot/* and lib/endorsed/* can live in the repository
>>> like happy little communistic jars should be :-P
>>>
>>> * * *
>>>
>>> And then there are longer term things for GShell...
>>>
>>> Remote administration (via, telnet, ssh, or custom ssl protocol...
>>> last is most likely to actually happen soonish)
>>>
>>> Process management, which is great for clusters, or staging ->
>>> production management. A full suite of command-line tools which can
>>> manage the configuration of a server... easily. So, for example,
>>> lets say you've got a configuration that is working really well for
>>> you... but you want to play with something new...
>>>
>>> So you might:
>>>
>>> ./bin/gsh backup-configuration before-mucking
>>> ./bin/gsh start-server
>>>
>>> And then go and change a whole bunch of stuff... and it doesn't
>>> work... yikes... so rollback...
>>>
>>> ./bin/gsh backup-configuration hosed-server
>>> ./bin/gsh restore-configuration before-mucking
>>> ./bin/gsh start-server
>>>
>>> And then maybe you want to play with the "hosed-server" configuration
>>> again...
>>>
>>> ./bin/gsh start-server --configuration hosed-server
>>>
>>> Of course, all of these could have been run from a single ./bin/gsh,
>>> but just for clarity, you can run them one off too.
>>>
>>> Maybe list or mange the configurations
>>>
>>> ./bin/gsh list-configurations
>>> ./bin/gsh remove-configuration some-unwanted-config
>>> ./bin/gsh copy-configuration default some-new-config
>>>
>>> The sky is the limit really... for what kind of management we can do...
>>>
>>> Lets say you wanted to do the above on a remote node?
>>>
>>> ./bin/gsh remote-shell someserver:9443
>>> Connecting to someserver:9447...
>>> Connected
>>>
>>> username: system
>>> password: **** (remember this is all jline, so we can mask
>>> passwords like one woudl expect)
>>>
>>> someserver:9447 > list-configurations
>>> someserver:9447 > remove-configuration some-unwanted-config
>>> someserver:9447 > copy-configuration default some-new-config
>>>
>>> So, all of these operations would happen on the node named
>>> "someserver" listening on 9443 (over ssl of course). Or how about
>>> you want to reboot a server remotely?
>>>
>>> someserver:9447 > restart-server now
>>> Geronimo server shutting down...
>>> ....
>>> Geronimo server shutdown.
>>> Geronimo server starting...
>>> ...
>>> Geronimo server started in ...
>>>
>>> Since GShell manages the processes its really easy to perform a full
>>> restart of a Server w/o needing magical platform scripting muck. And
>>> it will just work the same on each platform too.
>>>
>>> Once we have clustering, then we can do the same kinda thing for an
>>> entire cluster of nodes...
>>>
>>> someserver:9447 > restart-cluster now
>>> Shutting down 2 nodes...
>>> <node1> Geronimo server shutting down...
>>> <node1>....
>>> <node2> Geronimo server shutting down...
>>> <node2>....
>>> <node1>Geronimo server shutdown.
>>> <node2>Geronimo server shutdown.
>>> Starting up 2 nodes...
>>> <node1>Geronimo server starting...
>>> <node1>..
>>> <node2>Geronimo server starting...
>>> <node2>..
>>> <node1>Geronimo server started in ...
>>> <node2>Geronimo server started in ...
>>> Started up 2 nodes.
>>>
>>> And well, if you had some kinda script file which controlled say a
>>> logical grouping of nodes you could easily invoke that script (ya
>>> even on a remote system) and it will go and do it:
>>>
>>> someserver:9447 > script -l groovy
>>> local:file://restart-universe.groovy qa-universe
>>>
>>> The local: bit of the uri siginals the local URL handler to be used,
>>> which will cause the file://restart-universe.groovy to be loaded from
>>> the gsh instance where you are actually logged into (and ran the
>>> remote-shell gshell command) and will pipe its contents securely to
>>> the remote shell running on someserver:9447 and pass it to the script
>>> command to execute.
>>>
>>> The restart-universe.groovy might look something like this:
>>>
>>> <snip>
>>> import universe.Lookup
>>>
>>> assert args.size == 1 : 'Missing universe name'
>>>
>>> def universe = args[0]
>>>
>>> // Look up a list of nodes (for now say they are basically
>>> hostname:port)
>>> def nodes = Lookup.lookup(universe)
>>>
>>> log.info("Stopping universe ${universe}...")
>>> nodes.each { host ->
>>> shell.execute("remove-shell $host stop-server")
>>> }
>>> log.info("Universe ${universe} stopped")
>>>
>>> log.info("Starting universe ${universe}...")
>>> nodes.each { host ->
>>> shell.execute("remove-shell $host start-server")
>>> }
>>> log.info("Universe ${universe} started")
>>> </snip>
>>>
>>> Its kinda crude script, but I think you get the general point...
>>>
>>> * * *
>>>
>>> Anyways... I see... well, *HUGE* potential for this stuff...
>>>
>>> And really, a lot of what I just described above isn't that far into
>>> fantasy, its all relatively easy to implement on top of GShell... as
>>> it is now (or really as it was a year+ ago when I wrote it). Its
>>> really a matter of do others see the same value... and do others see
>>> the vision of using GShell as the core process launcher to allow
>>> things like "restart-server", or a "stop-server; copy-configuration
>>> default known-good; copy-configuration default testing;
>>> start-server", or that uber-fancy remote-shell muck.
>>>
>>> So, I'm gonna give y'all a few days to grok (or try to) what I've
>>> just spit out... please ask questions or comment, as I like to know
>>> I'm not just talking to myself here.
>>>
>>> And then maybe later next week, we might vote or come to some other
>>> consensus that this is the right direction for Geronimo, and well...
>>> then I'll make it become reality.
>>>
>>> Aighty, and now I'll shut up :-P
>>>
>>> --jason
>>>
>>>
>>>
>>> On Sep 8, 2007, at 11:53 AM, Jason Dillon wrote:
>>>
>>>> Aighty, well... I've done some long awaited re-factoring, and while
>>>> its still not _perfect_ its a whole lot better now IMO I think from
>>>> a framework perspective that its probably mature enough to take on
>>>> the task of being the server bootloader.
>>>>
>>>> I'm going to continue to refactor the guts of GShell over time, of
>>>> course... but I think that what is there now is highly usable for a
>>>> simple platform independent launcher, as well as for porting over
>>>> the other cli bits we have.
>>>>
>>>> I've done a lot of work in the past week, incase you didn't see the
>>>> storm of scm messages... pulled out pico, plopped in plexus, pulled
>>>> out commons-logging and commons-lang, which are suck and boated (in
>>>> that order). I've gotten the basic framework and supported classes
>>>> to use GShell down to ~ 1mb (a wee bit under)... though when I
>>>> started to add the layout.xml abstraction stuff, I had to pull in
>>>> xstream which bloated her back up to ~1.4m. I may eventually fix
>>>> that... or not, cause xstream is soooo very handy for xml -> object
>>>> stuff.
>>>>
>>>> I've fallen in love with annotations... they are *ucking great.
>>>> They work really well for handling the cli option and argument muck
>>>> which most every command needs to do. And striping out the
>>>> insano-sucking commons-cli really simplified command implementations
>>>> dramatically IMO.
>>>>
>>>> Anyways... I've make a heck of a lot of progress on cleaning up the
>>>> GShell framework... and more is to come I'm sure... But for now, I
>>>> think its probably ready for use primetime as the Geronimo Server's
>>>> bootloader.
>>>>
>>>> I think this provides a some significant value...
>>>>
>>>> 1) Platform scripts become consistent and relatively simple, easy to
>>>> maintain
>>>>
>>>> 2) Everyone will now have a consist way of launching the server,
>>>> even if you like a .sh, .bat, or java -jar, then end process that is
>>>> launched will be the same for everyone.
>>>>
>>>> 3) Opens up the door for some really nice and fancy fancy management
>>>> muck (like restarting the server from the web console, or cloning a
>>>> server instance or backing up a server instance...)
>>>>
>>>> 4) Lays the ground work for future features, like cluster
>>>> management, remote administration and scripting...
>>>>
>>>> * * *
>>>>
>>>> So, I think its time to decide... are we a go or no go for GShell as
>>>> the core CLI for Geronimo thingys and even more important, are we go
>>>> or no go for using GShell to boot up the server process?
>>>>
>>>> --jason
>>>>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jason Dillon <ja...@planet57.com>.
Ya, should be simple enough... though I don't want to keep
maintaining these extra assemblies, I'd like to just convert all of
the assemblies to use this stuff...
But if it helps ya out, I can make a geronimo-tomcat6-javaee5-gshell...
--jason
On Sep 8, 2007, at 12:52 PM, Jeff Genender wrote:
> Is this working for the Tomcat assembly? If not...can it soon?
>
> Thanks,
>
> Jeff
> Sent from my iPhone
>
> On Sep 8, 2007, at 1:40 PM, Jason Dillon <ja...@planet57.com> wrote:
>
>> A little bit more insight into what I'm thinking of doing... since
>> some of you can't read minds to well :-P
>>
>> I'd like to convert all of the assemblies to basically look like
>> what the assemblies/geronimo-jetty6-javaee5-gshell produces.
>>
>> And then I'd like to start converting the other cli bits to gshell
>> command impls, like: deployer, client and shutdown.
>>
>> And then (maybe around the same time or before the above), I'd
>> like to adapt the gshell of target jvm bits to load jars from the
>> repository, instead of using the lib/* bits.
>>
>> A little background for those who haven't looked at assemblies/
>> geronimo-jetty6-javaee5-gshell and what it produces from a lib/*
>> perspective. Right now I've set up the assembly to produce:
>>
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell
>>
>> Where the bits in lib/* and lib/endorsed/* are the same as they
>> were before. The bits in lib/boot/* and lib/gshell/* are specific
>> to gshell. And normally a gshell installation would have
>> everything I put into lib/gshell/* into lib/*, but I moved them to
>> a sub dir for now... since the bin/*.jar's load jars from the ../
>> lib/* dirs.
>>
>> The lib/boot/* stuff is the very minimal gshell bootstrap classes,
>> which setup up the other happiness... and let you do things like:
>>
>> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
>> boot/gshell-bootstrap.jar
>>
>> And that will give you a nice shell... or
>>
>> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
>> boot/gshell-bootstrap.jar start-server
>>
>> That will launch the G server process using all of the right -
>> Djava.ext.dirs and whatever properties that we currently have
>> hacked into platform scripts.
>>
>> Anyways, so the idea is to move all of the bits which are current
>> in the lib/* into the repository, and then configure the gshell
>> command impl to load put the correct dependency artifacts onto the
>> classpath of the target jvm that is booted up. This will augment
>> the existing kernel bootstrap from repo stuff, putting evertying
>> except what is needed from gshell into the repository...
>>
>> And really, what I'd like to eventually get to is having the
>> bootstrap from the repository... so that everything except for
>> what is now it lib/boot/* and lib/endorsed/* can live in the
>> repository like happy little communistic jars should be :-P
>>
>> * * *
>>
>> And then there are longer term things for GShell...
>>
>> Remote administration (via, telnet, ssh, or custom ssl protocol...
>> last is most likely to actually happen soonish)
>>
>> Process management, which is great for clusters, or staging ->
>> production management. A full suite of command-line tools which
>> can manage the configuration of a server... easily. So, for
>> example, lets say you've got a configuration that is working
>> really well for you... but you want to play with something new...
>>
>> So you might:
>>
>> ./bin/gsh backup-configuration before-mucking
>> ./bin/gsh start-server
>>
>> And then go and change a whole bunch of stuff... and it doesn't
>> work... yikes... so rollback...
>>
>> ./bin/gsh backup-configuration hosed-server
>> ./bin/gsh restore-configuration before-mucking
>> ./bin/gsh start-server
>>
>> And then maybe you want to play with the "hosed-server"
>> configuration again...
>>
>> ./bin/gsh start-server --configuration hosed-server
>>
>> Of course, all of these could have been run from a single ./bin/
>> gsh, but just for clarity, you can run them one off too.
>>
>> Maybe list or mange the configurations
>>
>> ./bin/gsh list-configurations
>> ./bin/gsh remove-configuration some-unwanted-config
>> ./bin/gsh copy-configuration default some-new-config
>>
>> The sky is the limit really... for what kind of management we can
>> do...
>>
>> Lets say you wanted to do the above on a remote node?
>>
>> ./bin/gsh remote-shell someserver:9443
>> Connecting to someserver:9447...
>> Connected
>>
>> username: system
>> password: **** (remember this is all jline, so we can mask
>> passwords like one woudl expect)
>>
>> someserver:9447 > list-configurations
>> someserver:9447 > remove-configuration some-unwanted-config
>> someserver:9447 > copy-configuration default some-new-config
>>
>> So, all of these operations would happen on the node named
>> "someserver" listening on 9443 (over ssl of course). Or how about
>> you want to reboot a server remotely?
>>
>> someserver:9447 > restart-server now
>> Geronimo server shutting down...
>> ....
>> Geronimo server shutdown.
>> Geronimo server starting...
>> ...
>> Geronimo server started in ...
>>
>> Since GShell manages the processes its really easy to perform a
>> full restart of a Server w/o needing magical platform scripting
>> muck. And it will just work the same on each platform too.
>>
>> Once we have clustering, then we can do the same kinda thing for
>> an entire cluster of nodes...
>>
>> someserver:9447 > restart-cluster now
>> Shutting down 2 nodes...
>> <node1> Geronimo server shutting down...
>> <node1>....
>> <node2> Geronimo server shutting down...
>> <node2>....
>> <node1>Geronimo server shutdown.
>> <node2>Geronimo server shutdown.
>> Starting up 2 nodes...
>> <node1>Geronimo server starting...
>> <node1>..
>> <node2>Geronimo server starting...
>> <node2>..
>> <node1>Geronimo server started in ...
>> <node2>Geronimo server started in ...
>> Started up 2 nodes.
>>
>> And well, if you had some kinda script file which controlled say a
>> logical grouping of nodes you could easily invoke that script (ya
>> even on a remote system) and it will go and do it:
>>
>> someserver:9447 > script -l groovy local:file://restart-
>> universe.groovy qa-universe
>>
>> The local: bit of the uri siginals the local URL handler to be
>> used, which will cause the file://restart-universe.groovy to be
>> loaded from the gsh instance where you are actually logged into
>> (and ran the remote-shell gshell command) and will pipe its
>> contents securely to the remote shell running on someserver:9447
>> and pass it to the script command to execute.
>>
>> The restart-universe.groovy might look something like this:
>>
>> <snip>
>> import universe.Lookup
>>
>> assert args.size == 1 : 'Missing universe name'
>>
>> def universe = args[0]
>>
>> // Look up a list of nodes (for now say they are basically
>> hostname:port)
>> def nodes = Lookup.lookup(universe)
>>
>> log.info("Stopping universe ${universe}...")
>> nodes.each { host ->
>> shell.execute("remove-shell $host stop-server")
>> }
>> log.info("Universe ${universe} stopped")
>>
>> log.info("Starting universe ${universe}...")
>> nodes.each { host ->
>> shell.execute("remove-shell $host start-server")
>> }
>> log.info("Universe ${universe} started")
>> </snip>
>>
>> Its kinda crude script, but I think you get the general point...
>>
>> * * *
>>
>> Anyways... I see... well, *HUGE* potential for this stuff...
>>
>> And really, a lot of what I just described above isn't that far
>> into fantasy, its all relatively easy to implement on top of
>> GShell... as it is now (or really as it was a year+ ago when I
>> wrote it). Its really a matter of do others see the same value...
>> and do others see the vision of using GShell as the core process
>> launcher to allow things like "restart-server", or a "stop-server;
>> copy-configuration default known-good; copy-configuration default
>> testing; start-server", or that uber-fancy remote-shell muck.
>>
>> So, I'm gonna give y'all a few days to grok (or try to) what I've
>> just spit out... please ask questions or comment, as I like to
>> know I'm not just talking to myself here.
>>
>> And then maybe later next week, we might vote or come to some
>> other consensus that this is the right direction for Geronimo, and
>> well... then I'll make it become reality.
>>
>> Aighty, and now I'll shut up :-P
>>
>> --jason
>>
>>
>>
>> On Sep 8, 2007, at 11:53 AM, Jason Dillon wrote:
>>
>>> Aighty, well... I've done some long awaited re-factoring, and
>>> while its still not _perfect_ its a whole lot better now IMO I
>>> think from a framework perspective that its probably mature
>>> enough to take on the task of being the server bootloader.
>>>
>>> I'm going to continue to refactor the guts of GShell over time,
>>> of course... but I think that what is there now is highly usable
>>> for a simple platform independent launcher, as well as for
>>> porting over the other cli bits we have.
>>>
>>> I've done a lot of work in the past week, incase you didn't see
>>> the storm of scm messages... pulled out pico, plopped in plexus,
>>> pulled out commons-logging and commons-lang, which are suck and
>>> boated (in that order). I've gotten the basic framework and
>>> supported classes to use GShell down to ~ 1mb (a wee bit
>>> under)... though when I started to add the layout.xml abstraction
>>> stuff, I had to pull in xstream which bloated her back up to
>>> ~1.4m. I may eventually fix that... or not, cause xstream is
>>> soooo very handy for xml -> object stuff.
>>>
>>> I've fallen in love with annotations... they are *ucking great.
>>> They work really well for handling the cli option and argument
>>> muck which most every command needs to do. And striping out the
>>> insano-sucking commons-cli really simplified command
>>> implementations dramatically IMO.
>>>
>>> Anyways... I've make a heck of a lot of progress on cleaning up
>>> the GShell framework... and more is to come I'm sure... But for
>>> now, I think its probably ready for use primetime as the Geronimo
>>> Server's bootloader.
>>>
>>> I think this provides a some significant value...
>>>
>>> 1) Platform scripts become consistent and relatively simple, easy
>>> to maintain
>>>
>>> 2) Everyone will now have a consist way of launching the server,
>>> even if you like a .sh, .bat, or java -jar, then end process that
>>> is launched will be the same for everyone.
>>>
>>> 3) Opens up the door for some really nice and fancy fancy
>>> management muck (like restarting the server from the web console,
>>> or cloning a server instance or backing up a server instance...)
>>>
>>> 4) Lays the ground work for future features, like cluster
>>> management, remote administration and scripting...
>>>
>>> * * *
>>>
>>> So, I think its time to decide... are we a go or no go for GShell
>>> as the core CLI for Geronimo thingys and even more important, are
>>> we go or no go for using GShell to boot up the server process?
>>>
>>> --jason
>>>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jason Dillon <ja...@planet57.com>.
Aighty, thanks Kevan, she builds for me now. Going to run through
some tests now to see if I've broken anything...
--jason
On Sep 13, 2007, at 10:27 AM, Kevan Miller wrote:
>
> On Sep 13, 2007, at 3:17 AM, Jason Dillon wrote:
>
>> I'm converting all of the assemblies tonight, should be done in
>> another hour or so.
>>
>> But, currently server/trunk is not building due to:
>>
>> <snip>
>> [INFO] Compiling 18 source files to /Users/jason/ws/geronimo/
>> server/modules/geronimo-openejb/target/classes
>> [INFO]
>> ---------------------------------------------------------------------
>> ---
>> [ERROR] BUILD FAILURE
>> [INFO]
>> ---------------------------------------------------------------------
>> ---
>> [INFO] Compilation failure
>>
>> /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/
>> java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[131,30]
>> cannot find symbol
>> symbol : variable service
>> location: class
>> org.apache.openejb.assembler.classic.TransactionServiceInfo
>>
>> /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/
>> java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[139,27]
>> cannot find symbol
>> symbol : variable service
>> location: class
>> org.apache.openejb.assembler.classic.SecurityServiceInfo
>>
>> /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/
>> java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[145,24]
>> cannot find symbol
>> symbol : variable service
>> location: class org.apache.openejb.assembler.classic.ProxyFactoryInfo
>> </snip>
>>
>> So, I can't verify that everything is super happy...
>
> I've deployed a new version of OpenEJB 3.0 snapshots. So, verify
> away... :-)
>
> You may need to delete old versions of OpenEJB snapshots from your
> maven repo (depending on when you built last...).
>
> --kevan
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Kevan Miller <ke...@gmail.com>.
On Sep 13, 2007, at 3:17 AM, Jason Dillon wrote:
> I'm converting all of the assemblies tonight, should be done in
> another hour or so.
>
> But, currently server/trunk is not building due to:
>
> <snip>
> [INFO] Compiling 18 source files to /Users/jason/ws/geronimo/server/
> modules/geronimo-openejb/target/classes
> [INFO]
> ----------------------------------------------------------------------
> --
> [ERROR] BUILD FAILURE
> [INFO]
> ----------------------------------------------------------------------
> --
> [INFO] Compilation failure
>
> /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/
> java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[131,30]
> cannot find symbol
> symbol : variable service
> location: class
> org.apache.openejb.assembler.classic.TransactionServiceInfo
>
> /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/
> java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[139,27]
> cannot find symbol
> symbol : variable service
> location: class
> org.apache.openejb.assembler.classic.SecurityServiceInfo
>
> /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/
> java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[145,24]
> cannot find symbol
> symbol : variable service
> location: class org.apache.openejb.assembler.classic.ProxyFactoryInfo
> </snip>
>
> So, I can't verify that everything is super happy...
I've deployed a new version of OpenEJB 3.0 snapshots. So, verify
away... :-)
You may need to delete old versions of OpenEJB snapshots from your
maven repo (depending on when you built last...).
--kevan
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jason Dillon <ja...@planet57.com>.
I'm converting all of the assemblies tonight, should be done in
another hour or so.
But, currently server/trunk is not building due to:
<snip>
[INFO] Compiling 18 source files to /Users/jason/ws/geronimo/server/
modules/geronimo-openejb/target/classes
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Compilation failure
/Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/
java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[131,30]
cannot find symbol
symbol : variable service
location: class
org.apache.openejb.assembler.classic.TransactionServiceInfo
/Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/
java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[139,27]
cannot find symbol
symbol : variable service
location: class org.apache.openejb.assembler.classic.SecurityServiceInfo
/Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/
java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[145,24]
cannot find symbol
symbol : variable service
location: class org.apache.openejb.assembler.classic.ProxyFactoryInfo
</snip>
So, I can't verify that everything is super happy...
--jason
On Sep 8, 2007, at 12:52 PM, Jeff Genender wrote:
> Is this working for the Tomcat assembly? If not...can it soon?
>
> Thanks,
>
> Jeff
> Sent from my iPhone
>
> On Sep 8, 2007, at 1:40 PM, Jason Dillon <ja...@planet57.com> wrote:
>
>> A little bit more insight into what I'm thinking of doing... since
>> some of you can't read minds to well :-P
>>
>> I'd like to convert all of the assemblies to basically look like
>> what the assemblies/geronimo-jetty6-javaee5-gshell produces.
>>
>> And then I'd like to start converting the other cli bits to gshell
>> command impls, like: deployer, client and shutdown.
>>
>> And then (maybe around the same time or before the above), I'd
>> like to adapt the gshell of target jvm bits to load jars from the
>> repository, instead of using the lib/* bits.
>>
>> A little background for those who haven't looked at assemblies/
>> geronimo-jetty6-javaee5-gshell and what it produces from a lib/*
>> perspective. Right now I've set up the assembly to produce:
>>
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell
>>
>> Where the bits in lib/* and lib/endorsed/* are the same as they
>> were before. The bits in lib/boot/* and lib/gshell/* are specific
>> to gshell. And normally a gshell installation would have
>> everything I put into lib/gshell/* into lib/*, but I moved them to
>> a sub dir for now... since the bin/*.jar's load jars from the ../
>> lib/* dirs.
>>
>> The lib/boot/* stuff is the very minimal gshell bootstrap classes,
>> which setup up the other happiness... and let you do things like:
>>
>> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
>> boot/gshell-bootstrap.jar
>>
>> And that will give you a nice shell... or
>>
>> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
>> boot/gshell-bootstrap.jar start-server
>>
>> That will launch the G server process using all of the right -
>> Djava.ext.dirs and whatever properties that we currently have
>> hacked into platform scripts.
>>
>> Anyways, so the idea is to move all of the bits which are current
>> in the lib/* into the repository, and then configure the gshell
>> command impl to load put the correct dependency artifacts onto the
>> classpath of the target jvm that is booted up. This will augment
>> the existing kernel bootstrap from repo stuff, putting evertying
>> except what is needed from gshell into the repository...
>>
>> And really, what I'd like to eventually get to is having the
>> bootstrap from the repository... so that everything except for
>> what is now it lib/boot/* and lib/endorsed/* can live in the
>> repository like happy little communistic jars should be :-P
>>
>> * * *
>>
>> And then there are longer term things for GShell...
>>
>> Remote administration (via, telnet, ssh, or custom ssl protocol...
>> last is most likely to actually happen soonish)
>>
>> Process management, which is great for clusters, or staging ->
>> production management. A full suite of command-line tools which
>> can manage the configuration of a server... easily. So, for
>> example, lets say you've got a configuration that is working
>> really well for you... but you want to play with something new...
>>
>> So you might:
>>
>> ./bin/gsh backup-configuration before-mucking
>> ./bin/gsh start-server
>>
>> And then go and change a whole bunch of stuff... and it doesn't
>> work... yikes... so rollback...
>>
>> ./bin/gsh backup-configuration hosed-server
>> ./bin/gsh restore-configuration before-mucking
>> ./bin/gsh start-server
>>
>> And then maybe you want to play with the "hosed-server"
>> configuration again...
>>
>> ./bin/gsh start-server --configuration hosed-server
>>
>> Of course, all of these could have been run from a single ./bin/
>> gsh, but just for clarity, you can run them one off too.
>>
>> Maybe list or mange the configurations
>>
>> ./bin/gsh list-configurations
>> ./bin/gsh remove-configuration some-unwanted-config
>> ./bin/gsh copy-configuration default some-new-config
>>
>> The sky is the limit really... for what kind of management we can
>> do...
>>
>> Lets say you wanted to do the above on a remote node?
>>
>> ./bin/gsh remote-shell someserver:9443
>> Connecting to someserver:9447...
>> Connected
>>
>> username: system
>> password: **** (remember this is all jline, so we can mask
>> passwords like one woudl expect)
>>
>> someserver:9447 > list-configurations
>> someserver:9447 > remove-configuration some-unwanted-config
>> someserver:9447 > copy-configuration default some-new-config
>>
>> So, all of these operations would happen on the node named
>> "someserver" listening on 9443 (over ssl of course). Or how about
>> you want to reboot a server remotely?
>>
>> someserver:9447 > restart-server now
>> Geronimo server shutting down...
>> ....
>> Geronimo server shutdown.
>> Geronimo server starting...
>> ...
>> Geronimo server started in ...
>>
>> Since GShell manages the processes its really easy to perform a
>> full restart of a Server w/o needing magical platform scripting
>> muck. And it will just work the same on each platform too.
>>
>> Once we have clustering, then we can do the same kinda thing for
>> an entire cluster of nodes...
>>
>> someserver:9447 > restart-cluster now
>> Shutting down 2 nodes...
>> <node1> Geronimo server shutting down...
>> <node1>....
>> <node2> Geronimo server shutting down...
>> <node2>....
>> <node1>Geronimo server shutdown.
>> <node2>Geronimo server shutdown.
>> Starting up 2 nodes...
>> <node1>Geronimo server starting...
>> <node1>..
>> <node2>Geronimo server starting...
>> <node2>..
>> <node1>Geronimo server started in ...
>> <node2>Geronimo server started in ...
>> Started up 2 nodes.
>>
>> And well, if you had some kinda script file which controlled say a
>> logical grouping of nodes you could easily invoke that script (ya
>> even on a remote system) and it will go and do it:
>>
>> someserver:9447 > script -l groovy local:file://restart-
>> universe.groovy qa-universe
>>
>> The local: bit of the uri siginals the local URL handler to be
>> used, which will cause the file://restart-universe.groovy to be
>> loaded from the gsh instance where you are actually logged into
>> (and ran the remote-shell gshell command) and will pipe its
>> contents securely to the remote shell running on someserver:9447
>> and pass it to the script command to execute.
>>
>> The restart-universe.groovy might look something like this:
>>
>> <snip>
>> import universe.Lookup
>>
>> assert args.size == 1 : 'Missing universe name'
>>
>> def universe = args[0]
>>
>> // Look up a list of nodes (for now say they are basically
>> hostname:port)
>> def nodes = Lookup.lookup(universe)
>>
>> log.info("Stopping universe ${universe}...")
>> nodes.each { host ->
>> shell.execute("remove-shell $host stop-server")
>> }
>> log.info("Universe ${universe} stopped")
>>
>> log.info("Starting universe ${universe}...")
>> nodes.each { host ->
>> shell.execute("remove-shell $host start-server")
>> }
>> log.info("Universe ${universe} started")
>> </snip>
>>
>> Its kinda crude script, but I think you get the general point...
>>
>> * * *
>>
>> Anyways... I see... well, *HUGE* potential for this stuff...
>>
>> And really, a lot of what I just described above isn't that far
>> into fantasy, its all relatively easy to implement on top of
>> GShell... as it is now (or really as it was a year+ ago when I
>> wrote it). Its really a matter of do others see the same value...
>> and do others see the vision of using GShell as the core process
>> launcher to allow things like "restart-server", or a "stop-server;
>> copy-configuration default known-good; copy-configuration default
>> testing; start-server", or that uber-fancy remote-shell muck.
>>
>> So, I'm gonna give y'all a few days to grok (or try to) what I've
>> just spit out... please ask questions or comment, as I like to
>> know I'm not just talking to myself here.
>>
>> And then maybe later next week, we might vote or come to some
>> other consensus that this is the right direction for Geronimo, and
>> well... then I'll make it become reality.
>>
>> Aighty, and now I'll shut up :-P
>>
>> --jason
>>
>>
>>
>> On Sep 8, 2007, at 11:53 AM, Jason Dillon wrote:
>>
>>> Aighty, well... I've done some long awaited re-factoring, and
>>> while its still not _perfect_ its a whole lot better now IMO I
>>> think from a framework perspective that its probably mature
>>> enough to take on the task of being the server bootloader.
>>>
>>> I'm going to continue to refactor the guts of GShell over time,
>>> of course... but I think that what is there now is highly usable
>>> for a simple platform independent launcher, as well as for
>>> porting over the other cli bits we have.
>>>
>>> I've done a lot of work in the past week, incase you didn't see
>>> the storm of scm messages... pulled out pico, plopped in plexus,
>>> pulled out commons-logging and commons-lang, which are suck and
>>> boated (in that order). I've gotten the basic framework and
>>> supported classes to use GShell down to ~ 1mb (a wee bit
>>> under)... though when I started to add the layout.xml abstraction
>>> stuff, I had to pull in xstream which bloated her back up to
>>> ~1.4m. I may eventually fix that... or not, cause xstream is
>>> soooo very handy for xml -> object stuff.
>>>
>>> I've fallen in love with annotations... they are *ucking great.
>>> They work really well for handling the cli option and argument
>>> muck which most every command needs to do. And striping out the
>>> insano-sucking commons-cli really simplified command
>>> implementations dramatically IMO.
>>>
>>> Anyways... I've make a heck of a lot of progress on cleaning up
>>> the GShell framework... and more is to come I'm sure... But for
>>> now, I think its probably ready for use primetime as the Geronimo
>>> Server's bootloader.
>>>
>>> I think this provides a some significant value...
>>>
>>> 1) Platform scripts become consistent and relatively simple, easy
>>> to maintain
>>>
>>> 2) Everyone will now have a consist way of launching the server,
>>> even if you like a .sh, .bat, or java -jar, then end process that
>>> is launched will be the same for everyone.
>>>
>>> 3) Opens up the door for some really nice and fancy fancy
>>> management muck (like restarting the server from the web console,
>>> or cloning a server instance or backing up a server instance...)
>>>
>>> 4) Lays the ground work for future features, like cluster
>>> management, remote administration and scripting...
>>>
>>> * * *
>>>
>>> So, I think its time to decide... are we a go or no go for GShell
>>> as the core CLI for Geronimo thingys and even more important, are
>>> we go or no go for using GShell to boot up the server process?
>>>
>>> --jason
>>>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Joe Bohn <jo...@earthlink.net>.
Jason Dillon wrote:
>
> Anyways... email for any reason. Aighty?
>
Hey Jason,
Before I realized the new gshell changes were introduced yesterday I
attempted to start the server the old fashioned way using ./geronimo.sh
run. This failed due to the assembly not containing the necessary yoko
bits in lib/endorsed.
As a hack I checked in a change to boilerplate-minimal to add those bits
back in lib/endorsed (http://svn.apache.org/viewvc?rev=575357&view=rev)
so I could get an assembly that would start the old way. BTW, I tried
this same change in boilderplate-javaee5 but it didn't have the desired
effect on the assemblies.
I'm not clear if we intend to keep things working with geronimo.sh or if
a similar change was even necessary to start the server using gshell
(perhaps it has some magic to dynamically create lib/endorsed?). So
please feel free to revert the change, provide recommendations for how I
should fix this, or make the necessary corrections to undo any damage I
may have done.
Now I'm off to play some with cool gshell :-) ...
Joe
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by David Jencks <da...@yahoo.com>.
BTW we should be careful of preserving the work Gianny did a while
back to reduce the number of jars that need to be in lib by providing
a bootstrap repository. (I don't understand exactly what he did,
this might not be exactly right). I was hoping we could take the
stax/jaxb jars back out of lib and thought I had an example of this
working.
thanks
david jencks
On Sep 14, 2007, at 10:46 AM, Paul McMahan wrote:
> Looking good. I ran into a couple of CNFE's while trying to
> install plugins using bin/deploy.sh. It was looking for the stax
> and jaxb classes. I hacked around that by manually adding the
> stax and jaxb jars from geronimo/lib to my classpath.
>
> Best wishes,
> Paul
>
>
> On Sep 13, 2007, at 6:11 AM, Jason Dillon wrote:
>
>> Aighty, I've converted *all* of the assemblies to include the new
>> GShell-based server launcher goodness.
>>
>> I'm still working on cleaning things up and adding more features
>> to the core GShell bits. And some things I'm going to change in
>> direct response to how we end up integrating it into Geronimo.
>>
>> I've already hooked up a custom GShell branding instance which
>> helps change the default welcome text/help text/version muck to be
>> Geronimo specific (and not GShell specific). This is the first
>> real usage of GShell being used to support another application
>> (um, the server) so I imagine that I'll (we'll) learn a little bit
>> about that and refactor the branding bits as we go along.
>>
>> * * *
>>
>> I did a few things... first, I've changed the boilerplate modules
>> to use the assembly module for most of the heavy lifting.
>>
>> And then I've put in the same structure that was in my POC
>> assembly into everything.
>>
>> So that means that everything now has these additional goodies:
>>
>> *Scripts
>>
>> bin/gsh
>> bin/gsh.bat
>> bin/start-server
>> bin/start-server.bat
>>
>> * Boot Jars
>>
>> lib/boot/gshell-bootstrap.jar
>> lib/boot/plexus-classworlds-1.2-alpha-10.jar
>>
>> * Runtime Jars
>>
>> lib/gshell/ant-1.7.0.jar
>> lib/gshell/ant-launcher-1.7.0.jar
>> lib/gshell/geronimo-commands-2.1-SNAPSHOT.jar
>> lib/gshell/groovy-all-1.1-beta-2.jar
>> lib/gshell/gshell-cli-1.0-alpha-1-SNAPSHOT.jar
>> lib/gshell/gshell-embeddable-1.0-alpha-1-SNAPSHOT.jar
>> lib/gshell/jcl104-over-slf4j-1.4.3.jar
>> lib/gshell/slf4j-log4j12-1.4.3.jar
>>
>> * Configuration
>>
>> etc/gsh-classworlds.conf
>> etc/gsh-log4j.properties
>> etc/layout.xml
>> etc/META-INF/plexus
>> etc/META-INF/plexus/plexus.xml
>>
>> * Example RC bits
>>
>> etc/rc.d/start-server,default.groovy
>>
>> And if you run the shell once, then you'll also find this:
>>
>> var/log/gshell.log
>>
>> I've left all of the other goodies there for now too, so for
>> example these both should do very similar things:
>>
>> bin/start-server
>> bin/geronimo run
>> bin/gsh -q start-server
>>
>> * * *
>>
>> I'm not sure if I broke anything in the process, so I'd really
>> appreciate it others could look this stuff over and provide some
>> feedback. I probably did break something... (sorry)... but I
>> can't tell at the moment due to the tree not being buildable.
>>
>> Remember I'm still whacking bits out... but if you think of
>> something you want/need that is related, please send mail (to the
>> list should do as long as the subject looks gshell-ish).
>>
>> My goal is to get *all* of the command-line bits for the server to
>> run through GShell, and use that experience to tighten up the
>> framework and hopefully provide some simple documentation to allow
>> other projects to easily consume the GShell for their application
>> needs. And in the process of doing all that I'm going to get that
>> 'remote-shell' command stuff working at least as a minimal
>> prototype. Might need to ping the network gurus for help after
>> the proto is working to finish up the design and make it truly
>> kick ass :-)
>>
>> Anyways... email for any reason. Aighty?
>>
>> Cheers,
>>
>> --jason
>>
>>
>> On Sep 8, 2007, at 12:52 PM, Jeff Genender wrote:
>>
>>> Is this working for the Tomcat assembly? If not...can it soon?
>>>
>>> Thanks,
>>>
>>> Jeff
>>> Sent from my iPhone
>>>
>>> On Sep 8, 2007, at 1:40 PM, Jason Dillon <ja...@planet57.com> wrote:
>>>
>>>> A little bit more insight into what I'm thinking of doing...
>>>> since some of you can't read minds to well :-P
>>>>
>>>> I'd like to convert all of the assemblies to basically look like
>>>> what the assemblies/geronimo-jetty6-javaee5-gshell produces.
>>>>
>>>> And then I'd like to start converting the other cli bits to
>>>> gshell command impls, like: deployer, client and shutdown.
>>>>
>>>> And then (maybe around the same time or before the above), I'd
>>>> like to adapt the gshell of target jvm bits to load jars from
>>>> the repository, instead of using the lib/* bits.
>>>>
>>>> A little background for those who haven't looked at assemblies/
>>>> geronimo-jetty6-javaee5-gshell and what it produces from a lib/*
>>>> perspective. Right now I've set up the assembly to produce:
>>>>
>>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib
>>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot
>>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed
>>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell
>>>>
>>>> Where the bits in lib/* and lib/endorsed/* are the same as they
>>>> were before. The bits in lib/boot/* and lib/gshell/* are
>>>> specific to gshell. And normally a gshell installation would
>>>> have everything I put into lib/gshell/* into lib/*, but I moved
>>>> them to a sub dir for now... since the bin/*.jar's load jars
>>>> from the ../lib/* dirs.
>>>>
>>>> The lib/boot/* stuff is the very minimal gshell bootstrap
>>>> classes, which setup up the other happiness... and let you do
>>>> things like:
>>>>
>>>> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
>>>> boot/gshell-bootstrap.jar
>>>>
>>>> And that will give you a nice shell... or
>>>>
>>>> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
>>>> boot/gshell-bootstrap.jar start-server
>>>>
>>>> That will launch the G server process using all of the right -
>>>> Djava.ext.dirs and whatever properties that we currently have
>>>> hacked into platform scripts.
>>>>
>>>> Anyways, so the idea is to move all of the bits which are
>>>> current in the lib/* into the repository, and then configure the
>>>> gshell command impl to load put the correct dependency artifacts
>>>> onto the classpath of the target jvm that is booted up. This
>>>> will augment the existing kernel bootstrap from repo stuff,
>>>> putting evertying except what is needed from gshell into the
>>>> repository...
>>>>
>>>> And really, what I'd like to eventually get to is having the
>>>> bootstrap from the repository... so that everything except for
>>>> what is now it lib/boot/* and lib/endorsed/* can live in the
>>>> repository like happy little communistic jars should be :-P
>>>>
>>>> * * *
>>>>
>>>> And then there are longer term things for GShell...
>>>>
>>>> Remote administration (via, telnet, ssh, or custom ssl
>>>> protocol... last is most likely to actually happen soonish)
>>>>
>>>> Process management, which is great for clusters, or staging ->
>>>> production management. A full suite of command-line tools which
>>>> can manage the configuration of a server... easily. So, for
>>>> example, lets say you've got a configuration that is working
>>>> really well for you... but you want to play with something new...
>>>>
>>>> So you might:
>>>>
>>>> ./bin/gsh backup-configuration before-mucking
>>>> ./bin/gsh start-server
>>>>
>>>> And then go and change a whole bunch of stuff... and it doesn't
>>>> work... yikes... so rollback...
>>>>
>>>> ./bin/gsh backup-configuration hosed-server
>>>> ./bin/gsh restore-configuration before-mucking
>>>> ./bin/gsh start-server
>>>>
>>>> And then maybe you want to play with the "hosed-server"
>>>> configuration again...
>>>>
>>>> ./bin/gsh start-server --configuration hosed-server
>>>>
>>>> Of course, all of these could have been run from a single ./bin/
>>>> gsh, but just for clarity, you can run them one off too.
>>>>
>>>> Maybe list or mange the configurations
>>>>
>>>> ./bin/gsh list-configurations
>>>> ./bin/gsh remove-configuration some-unwanted-config
>>>> ./bin/gsh copy-configuration default some-new-config
>>>>
>>>> The sky is the limit really... for what kind of management we
>>>> can do...
>>>>
>>>> Lets say you wanted to do the above on a remote node?
>>>>
>>>> ./bin/gsh remote-shell someserver:9443
>>>> Connecting to someserver:9447...
>>>> Connected
>>>>
>>>> username: system
>>>> password: **** (remember this is all jline, so we can mask
>>>> passwords like one woudl expect)
>>>>
>>>> someserver:9447 > list-configurations
>>>> someserver:9447 > remove-configuration some-unwanted-config
>>>> someserver:9447 > copy-configuration default some-new-config
>>>>
>>>> So, all of these operations would happen on the node named
>>>> "someserver" listening on 9443 (over ssl of course). Or how
>>>> about you want to reboot a server remotely?
>>>>
>>>> someserver:9447 > restart-server now
>>>> Geronimo server shutting down...
>>>> ....
>>>> Geronimo server shutdown.
>>>> Geronimo server starting...
>>>> ...
>>>> Geronimo server started in ...
>>>>
>>>> Since GShell manages the processes its really easy to perform a
>>>> full restart of a Server w/o needing magical platform scripting
>>>> muck. And it will just work the same on each platform too.
>>>>
>>>> Once we have clustering, then we can do the same kinda thing for
>>>> an entire cluster of nodes...
>>>>
>>>> someserver:9447 > restart-cluster now
>>>> Shutting down 2 nodes...
>>>> <node1> Geronimo server shutting down...
>>>> <node1>....
>>>> <node2> Geronimo server shutting down...
>>>> <node2>....
>>>> <node1>Geronimo server shutdown.
>>>> <node2>Geronimo server shutdown.
>>>> Starting up 2 nodes...
>>>> <node1>Geronimo server starting...
>>>> <node1>..
>>>> <node2>Geronimo server starting...
>>>> <node2>..
>>>> <node1>Geronimo server started in ...
>>>> <node2>Geronimo server started in ...
>>>> Started up 2 nodes.
>>>>
>>>> And well, if you had some kinda script file which controlled say
>>>> a logical grouping of nodes you could easily invoke that script
>>>> (ya even on a remote system) and it will go and do it:
>>>>
>>>> someserver:9447 > script -l groovy local:file://restart-
>>>> universe.groovy qa-universe
>>>>
>>>> The local: bit of the uri siginals the local URL handler to be
>>>> used, which will cause the file://restart-universe.groovy to be
>>>> loaded from the gsh instance where you are actually logged into
>>>> (and ran the remote-shell gshell command) and will pipe its
>>>> contents securely to the remote shell running on someserver:9447
>>>> and pass it to the script command to execute.
>>>>
>>>> The restart-universe.groovy might look something like this:
>>>>
>>>> <snip>
>>>> import universe.Lookup
>>>>
>>>> assert args.size == 1 : 'Missing universe name'
>>>>
>>>> def universe = args[0]
>>>>
>>>> // Look up a list of nodes (for now say they are basically
>>>> hostname:port)
>>>> def nodes = Lookup.lookup(universe)
>>>>
>>>> log.info("Stopping universe ${universe}...")
>>>> nodes.each { host ->
>>>> shell.execute("remove-shell $host stop-server")
>>>> }
>>>> log.info("Universe ${universe} stopped")
>>>>
>>>> log.info("Starting universe ${universe}...")
>>>> nodes.each { host ->
>>>> shell.execute("remove-shell $host start-server")
>>>> }
>>>> log.info("Universe ${universe} started")
>>>> </snip>
>>>>
>>>> Its kinda crude script, but I think you get the general point...
>>>>
>>>> * * *
>>>>
>>>> Anyways... I see... well, *HUGE* potential for this stuff...
>>>>
>>>> And really, a lot of what I just described above isn't that far
>>>> into fantasy, its all relatively easy to implement on top of
>>>> GShell... as it is now (or really as it was a year+ ago when I
>>>> wrote it). Its really a matter of do others see the same
>>>> value... and do others see the vision of using GShell as the
>>>> core process launcher to allow things like "restart-server", or
>>>> a "stop-server; copy-configuration default known-good; copy-
>>>> configuration default testing; start-server", or that uber-fancy
>>>> remote-shell muck.
>>>>
>>>> So, I'm gonna give y'all a few days to grok (or try to) what
>>>> I've just spit out... please ask questions or comment, as I like
>>>> to know I'm not just talking to myself here.
>>>>
>>>> And then maybe later next week, we might vote or come to some
>>>> other consensus that this is the right direction for Geronimo,
>>>> and well... then I'll make it become reality.
>>>>
>>>> Aighty, and now I'll shut up :-P
>>>>
>>>> --jason
>>>>
>>>>
>>>>
>>>> On Sep 8, 2007, at 11:53 AM, Jason Dillon wrote:
>>>>
>>>>> Aighty, well... I've done some long awaited re-factoring, and
>>>>> while its still not _perfect_ its a whole lot better now IMO I
>>>>> think from a framework perspective that its probably mature
>>>>> enough to take on the task of being the server bootloader.
>>>>>
>>>>> I'm going to continue to refactor the guts of GShell over time,
>>>>> of course... but I think that what is there now is highly
>>>>> usable for a simple platform independent launcher, as well as
>>>>> for porting over the other cli bits we have.
>>>>>
>>>>> I've done a lot of work in the past week, incase you didn't see
>>>>> the storm of scm messages... pulled out pico, plopped in
>>>>> plexus, pulled out commons-logging and commons-lang, which are
>>>>> suck and boated (in that order). I've gotten the basic
>>>>> framework and supported classes to use GShell down to ~ 1mb (a
>>>>> wee bit under)... though when I started to add the layout.xml
>>>>> abstraction stuff, I had to pull in xstream which bloated her
>>>>> back up to ~1.4m. I may eventually fix that... or not, cause
>>>>> xstream is soooo very handy for xml -> object stuff.
>>>>>
>>>>> I've fallen in love with annotations... they are *ucking
>>>>> great. They work really well for handling the cli option and
>>>>> argument muck which most every command needs to do. And
>>>>> striping out the insano-sucking commons-cli really simplified
>>>>> command implementations dramatically IMO.
>>>>>
>>>>> Anyways... I've make a heck of a lot of progress on cleaning up
>>>>> the GShell framework... and more is to come I'm sure... But
>>>>> for now, I think its probably ready for use primetime as the
>>>>> Geronimo Server's bootloader.
>>>>>
>>>>> I think this provides a some significant value...
>>>>>
>>>>> 1) Platform scripts become consistent and relatively simple,
>>>>> easy to maintain
>>>>>
>>>>> 2) Everyone will now have a consist way of launching the
>>>>> server, even if you like a .sh, .bat, or java -jar, then end
>>>>> process that is launched will be the same for everyone.
>>>>>
>>>>> 3) Opens up the door for some really nice and fancy fancy
>>>>> management muck (like restarting the server from the web
>>>>> console, or cloning a server instance or backing up a server
>>>>> instance...)
>>>>>
>>>>> 4) Lays the ground work for future features, like cluster
>>>>> management, remote administration and scripting...
>>>>>
>>>>> * * *
>>>>>
>>>>> So, I think its time to decide... are we a go or no go for
>>>>> GShell as the core CLI for Geronimo thingys and even more
>>>>> important, are we go or no go for using GShell to boot up the
>>>>> server process?
>>>>>
>>>>> --jason
>>>>>
>>
>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Paul McMahan <pa...@gmail.com>.
Looking good. I ran into a couple of CNFE's while trying to install
plugins using bin/deploy.sh. It was looking for the stax and jaxb
classes. I hacked around that by manually adding the stax and jaxb
jars from geronimo/lib to my classpath.
Best wishes,
Paul
On Sep 13, 2007, at 6:11 AM, Jason Dillon wrote:
> Aighty, I've converted *all* of the assemblies to include the new
> GShell-based server launcher goodness.
>
> I'm still working on cleaning things up and adding more features to
> the core GShell bits. And some things I'm going to change in
> direct response to how we end up integrating it into Geronimo.
>
> I've already hooked up a custom GShell branding instance which
> helps change the default welcome text/help text/version muck to be
> Geronimo specific (and not GShell specific). This is the first
> real usage of GShell being used to support another application (um,
> the server) so I imagine that I'll (we'll) learn a little bit about
> that and refactor the branding bits as we go along.
>
> * * *
>
> I did a few things... first, I've changed the boilerplate modules
> to use the assembly module for most of the heavy lifting.
>
> And then I've put in the same structure that was in my POC assembly
> into everything.
>
> So that means that everything now has these additional goodies:
>
> *Scripts
>
> bin/gsh
> bin/gsh.bat
> bin/start-server
> bin/start-server.bat
>
> * Boot Jars
>
> lib/boot/gshell-bootstrap.jar
> lib/boot/plexus-classworlds-1.2-alpha-10.jar
>
> * Runtime Jars
>
> lib/gshell/ant-1.7.0.jar
> lib/gshell/ant-launcher-1.7.0.jar
> lib/gshell/geronimo-commands-2.1-SNAPSHOT.jar
> lib/gshell/groovy-all-1.1-beta-2.jar
> lib/gshell/gshell-cli-1.0-alpha-1-SNAPSHOT.jar
> lib/gshell/gshell-embeddable-1.0-alpha-1-SNAPSHOT.jar
> lib/gshell/jcl104-over-slf4j-1.4.3.jar
> lib/gshell/slf4j-log4j12-1.4.3.jar
>
> * Configuration
>
> etc/gsh-classworlds.conf
> etc/gsh-log4j.properties
> etc/layout.xml
> etc/META-INF/plexus
> etc/META-INF/plexus/plexus.xml
>
> * Example RC bits
>
> etc/rc.d/start-server,default.groovy
>
> And if you run the shell once, then you'll also find this:
>
> var/log/gshell.log
>
> I've left all of the other goodies there for now too, so for
> example these both should do very similar things:
>
> bin/start-server
> bin/geronimo run
> bin/gsh -q start-server
>
> * * *
>
> I'm not sure if I broke anything in the process, so I'd really
> appreciate it others could look this stuff over and provide some
> feedback. I probably did break something... (sorry)... but I can't
> tell at the moment due to the tree not being buildable.
>
> Remember I'm still whacking bits out... but if you think of
> something you want/need that is related, please send mail (to the
> list should do as long as the subject looks gshell-ish).
>
> My goal is to get *all* of the command-line bits for the server to
> run through GShell, and use that experience to tighten up the
> framework and hopefully provide some simple documentation to allow
> other projects to easily consume the GShell for their application
> needs. And in the process of doing all that I'm going to get that
> 'remote-shell' command stuff working at least as a minimal
> prototype. Might need to ping the network gurus for help after the
> proto is working to finish up the design and make it truly kick
> ass :-)
>
> Anyways... email for any reason. Aighty?
>
> Cheers,
>
> --jason
>
>
> On Sep 8, 2007, at 12:52 PM, Jeff Genender wrote:
>
>> Is this working for the Tomcat assembly? If not...can it soon?
>>
>> Thanks,
>>
>> Jeff
>> Sent from my iPhone
>>
>> On Sep 8, 2007, at 1:40 PM, Jason Dillon <ja...@planet57.com> wrote:
>>
>>> A little bit more insight into what I'm thinking of doing...
>>> since some of you can't read minds to well :-P
>>>
>>> I'd like to convert all of the assemblies to basically look like
>>> what the assemblies/geronimo-jetty6-javaee5-gshell produces.
>>>
>>> And then I'd like to start converting the other cli bits to
>>> gshell command impls, like: deployer, client and shutdown.
>>>
>>> And then (maybe around the same time or before the above), I'd
>>> like to adapt the gshell of target jvm bits to load jars from the
>>> repository, instead of using the lib/* bits.
>>>
>>> A little background for those who haven't looked at assemblies/
>>> geronimo-jetty6-javaee5-gshell and what it produces from a lib/*
>>> perspective. Right now I've set up the assembly to produce:
>>>
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed
>>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell
>>>
>>> Where the bits in lib/* and lib/endorsed/* are the same as they
>>> were before. The bits in lib/boot/* and lib/gshell/* are
>>> specific to gshell. And normally a gshell installation would
>>> have everything I put into lib/gshell/* into lib/*, but I moved
>>> them to a sub dir for now... since the bin/*.jar's load jars from
>>> the ../lib/* dirs.
>>>
>>> The lib/boot/* stuff is the very minimal gshell bootstrap
>>> classes, which setup up the other happiness... and let you do
>>> things like:
>>>
>>> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
>>> boot/gshell-bootstrap.jar
>>>
>>> And that will give you a nice shell... or
>>>
>>> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
>>> boot/gshell-bootstrap.jar start-server
>>>
>>> That will launch the G server process using all of the right -
>>> Djava.ext.dirs and whatever properties that we currently have
>>> hacked into platform scripts.
>>>
>>> Anyways, so the idea is to move all of the bits which are current
>>> in the lib/* into the repository, and then configure the gshell
>>> command impl to load put the correct dependency artifacts onto
>>> the classpath of the target jvm that is booted up. This will
>>> augment the existing kernel bootstrap from repo stuff, putting
>>> evertying except what is needed from gshell into the repository...
>>>
>>> And really, what I'd like to eventually get to is having the
>>> bootstrap from the repository... so that everything except for
>>> what is now it lib/boot/* and lib/endorsed/* can live in the
>>> repository like happy little communistic jars should be :-P
>>>
>>> * * *
>>>
>>> And then there are longer term things for GShell...
>>>
>>> Remote administration (via, telnet, ssh, or custom ssl
>>> protocol... last is most likely to actually happen soonish)
>>>
>>> Process management, which is great for clusters, or staging ->
>>> production management. A full suite of command-line tools which
>>> can manage the configuration of a server... easily. So, for
>>> example, lets say you've got a configuration that is working
>>> really well for you... but you want to play with something new...
>>>
>>> So you might:
>>>
>>> ./bin/gsh backup-configuration before-mucking
>>> ./bin/gsh start-server
>>>
>>> And then go and change a whole bunch of stuff... and it doesn't
>>> work... yikes... so rollback...
>>>
>>> ./bin/gsh backup-configuration hosed-server
>>> ./bin/gsh restore-configuration before-mucking
>>> ./bin/gsh start-server
>>>
>>> And then maybe you want to play with the "hosed-server"
>>> configuration again...
>>>
>>> ./bin/gsh start-server --configuration hosed-server
>>>
>>> Of course, all of these could have been run from a single ./bin/
>>> gsh, but just for clarity, you can run them one off too.
>>>
>>> Maybe list or mange the configurations
>>>
>>> ./bin/gsh list-configurations
>>> ./bin/gsh remove-configuration some-unwanted-config
>>> ./bin/gsh copy-configuration default some-new-config
>>>
>>> The sky is the limit really... for what kind of management we can
>>> do...
>>>
>>> Lets say you wanted to do the above on a remote node?
>>>
>>> ./bin/gsh remote-shell someserver:9443
>>> Connecting to someserver:9447...
>>> Connected
>>>
>>> username: system
>>> password: **** (remember this is all jline, so we can mask
>>> passwords like one woudl expect)
>>>
>>> someserver:9447 > list-configurations
>>> someserver:9447 > remove-configuration some-unwanted-config
>>> someserver:9447 > copy-configuration default some-new-config
>>>
>>> So, all of these operations would happen on the node named
>>> "someserver" listening on 9443 (over ssl of course). Or how
>>> about you want to reboot a server remotely?
>>>
>>> someserver:9447 > restart-server now
>>> Geronimo server shutting down...
>>> ....
>>> Geronimo server shutdown.
>>> Geronimo server starting...
>>> ...
>>> Geronimo server started in ...
>>>
>>> Since GShell manages the processes its really easy to perform a
>>> full restart of a Server w/o needing magical platform scripting
>>> muck. And it will just work the same on each platform too.
>>>
>>> Once we have clustering, then we can do the same kinda thing for
>>> an entire cluster of nodes...
>>>
>>> someserver:9447 > restart-cluster now
>>> Shutting down 2 nodes...
>>> <node1> Geronimo server shutting down...
>>> <node1>....
>>> <node2> Geronimo server shutting down...
>>> <node2>....
>>> <node1>Geronimo server shutdown.
>>> <node2>Geronimo server shutdown.
>>> Starting up 2 nodes...
>>> <node1>Geronimo server starting...
>>> <node1>..
>>> <node2>Geronimo server starting...
>>> <node2>..
>>> <node1>Geronimo server started in ...
>>> <node2>Geronimo server started in ...
>>> Started up 2 nodes.
>>>
>>> And well, if you had some kinda script file which controlled say
>>> a logical grouping of nodes you could easily invoke that script
>>> (ya even on a remote system) and it will go and do it:
>>>
>>> someserver:9447 > script -l groovy local:file://restart-
>>> universe.groovy qa-universe
>>>
>>> The local: bit of the uri siginals the local URL handler to be
>>> used, which will cause the file://restart-universe.groovy to be
>>> loaded from the gsh instance where you are actually logged into
>>> (and ran the remote-shell gshell command) and will pipe its
>>> contents securely to the remote shell running on someserver:9447
>>> and pass it to the script command to execute.
>>>
>>> The restart-universe.groovy might look something like this:
>>>
>>> <snip>
>>> import universe.Lookup
>>>
>>> assert args.size == 1 : 'Missing universe name'
>>>
>>> def universe = args[0]
>>>
>>> // Look up a list of nodes (for now say they are basically
>>> hostname:port)
>>> def nodes = Lookup.lookup(universe)
>>>
>>> log.info("Stopping universe ${universe}...")
>>> nodes.each { host ->
>>> shell.execute("remove-shell $host stop-server")
>>> }
>>> log.info("Universe ${universe} stopped")
>>>
>>> log.info("Starting universe ${universe}...")
>>> nodes.each { host ->
>>> shell.execute("remove-shell $host start-server")
>>> }
>>> log.info("Universe ${universe} started")
>>> </snip>
>>>
>>> Its kinda crude script, but I think you get the general point...
>>>
>>> * * *
>>>
>>> Anyways... I see... well, *HUGE* potential for this stuff...
>>>
>>> And really, a lot of what I just described above isn't that far
>>> into fantasy, its all relatively easy to implement on top of
>>> GShell... as it is now (or really as it was a year+ ago when I
>>> wrote it). Its really a matter of do others see the same
>>> value... and do others see the vision of using GShell as the core
>>> process launcher to allow things like "restart-server", or a
>>> "stop-server; copy-configuration default known-good; copy-
>>> configuration default testing; start-server", or that uber-fancy
>>> remote-shell muck.
>>>
>>> So, I'm gonna give y'all a few days to grok (or try to) what I've
>>> just spit out... please ask questions or comment, as I like to
>>> know I'm not just talking to myself here.
>>>
>>> And then maybe later next week, we might vote or come to some
>>> other consensus that this is the right direction for Geronimo,
>>> and well... then I'll make it become reality.
>>>
>>> Aighty, and now I'll shut up :-P
>>>
>>> --jason
>>>
>>>
>>>
>>> On Sep 8, 2007, at 11:53 AM, Jason Dillon wrote:
>>>
>>>> Aighty, well... I've done some long awaited re-factoring, and
>>>> while its still not _perfect_ its a whole lot better now IMO I
>>>> think from a framework perspective that its probably mature
>>>> enough to take on the task of being the server bootloader.
>>>>
>>>> I'm going to continue to refactor the guts of GShell over time,
>>>> of course... but I think that what is there now is highly usable
>>>> for a simple platform independent launcher, as well as for
>>>> porting over the other cli bits we have.
>>>>
>>>> I've done a lot of work in the past week, incase you didn't see
>>>> the storm of scm messages... pulled out pico, plopped in plexus,
>>>> pulled out commons-logging and commons-lang, which are suck and
>>>> boated (in that order). I've gotten the basic framework and
>>>> supported classes to use GShell down to ~ 1mb (a wee bit
>>>> under)... though when I started to add the layout.xml
>>>> abstraction stuff, I had to pull in xstream which bloated her
>>>> back up to ~1.4m. I may eventually fix that... or not, cause
>>>> xstream is soooo very handy for xml -> object stuff.
>>>>
>>>> I've fallen in love with annotations... they are *ucking great.
>>>> They work really well for handling the cli option and argument
>>>> muck which most every command needs to do. And striping out the
>>>> insano-sucking commons-cli really simplified command
>>>> implementations dramatically IMO.
>>>>
>>>> Anyways... I've make a heck of a lot of progress on cleaning up
>>>> the GShell framework... and more is to come I'm sure... But for
>>>> now, I think its probably ready for use primetime as the
>>>> Geronimo Server's bootloader.
>>>>
>>>> I think this provides a some significant value...
>>>>
>>>> 1) Platform scripts become consistent and relatively simple,
>>>> easy to maintain
>>>>
>>>> 2) Everyone will now have a consist way of launching the server,
>>>> even if you like a .sh, .bat, or java -jar, then end process
>>>> that is launched will be the same for everyone.
>>>>
>>>> 3) Opens up the door for some really nice and fancy fancy
>>>> management muck (like restarting the server from the web
>>>> console, or cloning a server instance or backing up a server
>>>> instance...)
>>>>
>>>> 4) Lays the ground work for future features, like cluster
>>>> management, remote administration and scripting...
>>>>
>>>> * * *
>>>>
>>>> So, I think its time to decide... are we a go or no go for
>>>> GShell as the core CLI for Geronimo thingys and even more
>>>> important, are we go or no go for using GShell to boot up the
>>>> server process?
>>>>
>>>> --jason
>>>>
>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jason Dillon <ja...@planet57.com>.
Aighty, I've converted *all* of the assemblies to include the new
GShell-based server launcher goodness.
I'm still working on cleaning things up and adding more features to
the core GShell bits. And some things I'm going to change in direct
response to how we end up integrating it into Geronimo.
I've already hooked up a custom GShell branding instance which helps
change the default welcome text/help text/version muck to be Geronimo
specific (and not GShell specific). This is the first real usage of
GShell being used to support another application (um, the server) so
I imagine that I'll (we'll) learn a little bit about that and
refactor the branding bits as we go along.
* * *
I did a few things... first, I've changed the boilerplate modules to
use the assembly module for most of the heavy lifting.
And then I've put in the same structure that was in my POC assembly
into everything.
So that means that everything now has these additional goodies:
*Scripts
bin/gsh
bin/gsh.bat
bin/start-server
bin/start-server.bat
* Boot Jars
lib/boot/gshell-bootstrap.jar
lib/boot/plexus-classworlds-1.2-alpha-10.jar
* Runtime Jars
lib/gshell/ant-1.7.0.jar
lib/gshell/ant-launcher-1.7.0.jar
lib/gshell/geronimo-commands-2.1-SNAPSHOT.jar
lib/gshell/groovy-all-1.1-beta-2.jar
lib/gshell/gshell-cli-1.0-alpha-1-SNAPSHOT.jar
lib/gshell/gshell-embeddable-1.0-alpha-1-SNAPSHOT.jar
lib/gshell/jcl104-over-slf4j-1.4.3.jar
lib/gshell/slf4j-log4j12-1.4.3.jar
* Configuration
etc/gsh-classworlds.conf
etc/gsh-log4j.properties
etc/layout.xml
etc/META-INF/plexus
etc/META-INF/plexus/plexus.xml
* Example RC bits
etc/rc.d/start-server,default.groovy
And if you run the shell once, then you'll also find this:
var/log/gshell.log
I've left all of the other goodies there for now too, so for example
these both should do very similar things:
bin/start-server
bin/geronimo run
bin/gsh -q start-server
* * *
I'm not sure if I broke anything in the process, so I'd really
appreciate it others could look this stuff over and provide some
feedback. I probably did break something... (sorry)... but I can't
tell at the moment due to the tree not being buildable.
Remember I'm still whacking bits out... but if you think of something
you want/need that is related, please send mail (to the list should
do as long as the subject looks gshell-ish).
My goal is to get *all* of the command-line bits for the server to
run through GShell, and use that experience to tighten up the
framework and hopefully provide some simple documentation to allow
other projects to easily consume the GShell for their application
needs. And in the process of doing all that I'm going to get that
'remote-shell' command stuff working at least as a minimal
prototype. Might need to ping the network gurus for help after the
proto is working to finish up the design and make it truly kick ass :-)
Anyways... email for any reason. Aighty?
Cheers,
--jason
On Sep 8, 2007, at 12:52 PM, Jeff Genender wrote:
> Is this working for the Tomcat assembly? If not...can it soon?
>
> Thanks,
>
> Jeff
> Sent from my iPhone
>
> On Sep 8, 2007, at 1:40 PM, Jason Dillon <ja...@planet57.com> wrote:
>
>> A little bit more insight into what I'm thinking of doing... since
>> some of you can't read minds to well :-P
>>
>> I'd like to convert all of the assemblies to basically look like
>> what the assemblies/geronimo-jetty6-javaee5-gshell produces.
>>
>> And then I'd like to start converting the other cli bits to gshell
>> command impls, like: deployer, client and shutdown.
>>
>> And then (maybe around the same time or before the above), I'd
>> like to adapt the gshell of target jvm bits to load jars from the
>> repository, instead of using the lib/* bits.
>>
>> A little background for those who haven't looked at assemblies/
>> geronimo-jetty6-javaee5-gshell and what it produces from a lib/*
>> perspective. Right now I've set up the assembly to produce:
>>
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed
>> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell
>>
>> Where the bits in lib/* and lib/endorsed/* are the same as they
>> were before. The bits in lib/boot/* and lib/gshell/* are specific
>> to gshell. And normally a gshell installation would have
>> everything I put into lib/gshell/* into lib/*, but I moved them to
>> a sub dir for now... since the bin/*.jar's load jars from the ../
>> lib/* dirs.
>>
>> The lib/boot/* stuff is the very minimal gshell bootstrap classes,
>> which setup up the other happiness... and let you do things like:
>>
>> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
>> boot/gshell-bootstrap.jar
>>
>> And that will give you a nice shell... or
>>
>> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
>> boot/gshell-bootstrap.jar start-server
>>
>> That will launch the G server process using all of the right -
>> Djava.ext.dirs and whatever properties that we currently have
>> hacked into platform scripts.
>>
>> Anyways, so the idea is to move all of the bits which are current
>> in the lib/* into the repository, and then configure the gshell
>> command impl to load put the correct dependency artifacts onto the
>> classpath of the target jvm that is booted up. This will augment
>> the existing kernel bootstrap from repo stuff, putting evertying
>> except what is needed from gshell into the repository...
>>
>> And really, what I'd like to eventually get to is having the
>> bootstrap from the repository... so that everything except for
>> what is now it lib/boot/* and lib/endorsed/* can live in the
>> repository like happy little communistic jars should be :-P
>>
>> * * *
>>
>> And then there are longer term things for GShell...
>>
>> Remote administration (via, telnet, ssh, or custom ssl protocol...
>> last is most likely to actually happen soonish)
>>
>> Process management, which is great for clusters, or staging ->
>> production management. A full suite of command-line tools which
>> can manage the configuration of a server... easily. So, for
>> example, lets say you've got a configuration that is working
>> really well for you... but you want to play with something new...
>>
>> So you might:
>>
>> ./bin/gsh backup-configuration before-mucking
>> ./bin/gsh start-server
>>
>> And then go and change a whole bunch of stuff... and it doesn't
>> work... yikes... so rollback...
>>
>> ./bin/gsh backup-configuration hosed-server
>> ./bin/gsh restore-configuration before-mucking
>> ./bin/gsh start-server
>>
>> And then maybe you want to play with the "hosed-server"
>> configuration again...
>>
>> ./bin/gsh start-server --configuration hosed-server
>>
>> Of course, all of these could have been run from a single ./bin/
>> gsh, but just for clarity, you can run them one off too.
>>
>> Maybe list or mange the configurations
>>
>> ./bin/gsh list-configurations
>> ./bin/gsh remove-configuration some-unwanted-config
>> ./bin/gsh copy-configuration default some-new-config
>>
>> The sky is the limit really... for what kind of management we can
>> do...
>>
>> Lets say you wanted to do the above on a remote node?
>>
>> ./bin/gsh remote-shell someserver:9443
>> Connecting to someserver:9447...
>> Connected
>>
>> username: system
>> password: **** (remember this is all jline, so we can mask
>> passwords like one woudl expect)
>>
>> someserver:9447 > list-configurations
>> someserver:9447 > remove-configuration some-unwanted-config
>> someserver:9447 > copy-configuration default some-new-config
>>
>> So, all of these operations would happen on the node named
>> "someserver" listening on 9443 (over ssl of course). Or how about
>> you want to reboot a server remotely?
>>
>> someserver:9447 > restart-server now
>> Geronimo server shutting down...
>> ....
>> Geronimo server shutdown.
>> Geronimo server starting...
>> ...
>> Geronimo server started in ...
>>
>> Since GShell manages the processes its really easy to perform a
>> full restart of a Server w/o needing magical platform scripting
>> muck. And it will just work the same on each platform too.
>>
>> Once we have clustering, then we can do the same kinda thing for
>> an entire cluster of nodes...
>>
>> someserver:9447 > restart-cluster now
>> Shutting down 2 nodes...
>> <node1> Geronimo server shutting down...
>> <node1>....
>> <node2> Geronimo server shutting down...
>> <node2>....
>> <node1>Geronimo server shutdown.
>> <node2>Geronimo server shutdown.
>> Starting up 2 nodes...
>> <node1>Geronimo server starting...
>> <node1>..
>> <node2>Geronimo server starting...
>> <node2>..
>> <node1>Geronimo server started in ...
>> <node2>Geronimo server started in ...
>> Started up 2 nodes.
>>
>> And well, if you had some kinda script file which controlled say a
>> logical grouping of nodes you could easily invoke that script (ya
>> even on a remote system) and it will go and do it:
>>
>> someserver:9447 > script -l groovy local:file://restart-
>> universe.groovy qa-universe
>>
>> The local: bit of the uri siginals the local URL handler to be
>> used, which will cause the file://restart-universe.groovy to be
>> loaded from the gsh instance where you are actually logged into
>> (and ran the remote-shell gshell command) and will pipe its
>> contents securely to the remote shell running on someserver:9447
>> and pass it to the script command to execute.
>>
>> The restart-universe.groovy might look something like this:
>>
>> <snip>
>> import universe.Lookup
>>
>> assert args.size == 1 : 'Missing universe name'
>>
>> def universe = args[0]
>>
>> // Look up a list of nodes (for now say they are basically
>> hostname:port)
>> def nodes = Lookup.lookup(universe)
>>
>> log.info("Stopping universe ${universe}...")
>> nodes.each { host ->
>> shell.execute("remove-shell $host stop-server")
>> }
>> log.info("Universe ${universe} stopped")
>>
>> log.info("Starting universe ${universe}...")
>> nodes.each { host ->
>> shell.execute("remove-shell $host start-server")
>> }
>> log.info("Universe ${universe} started")
>> </snip>
>>
>> Its kinda crude script, but I think you get the general point...
>>
>> * * *
>>
>> Anyways... I see... well, *HUGE* potential for this stuff...
>>
>> And really, a lot of what I just described above isn't that far
>> into fantasy, its all relatively easy to implement on top of
>> GShell... as it is now (or really as it was a year+ ago when I
>> wrote it). Its really a matter of do others see the same value...
>> and do others see the vision of using GShell as the core process
>> launcher to allow things like "restart-server", or a "stop-server;
>> copy-configuration default known-good; copy-configuration default
>> testing; start-server", or that uber-fancy remote-shell muck.
>>
>> So, I'm gonna give y'all a few days to grok (or try to) what I've
>> just spit out... please ask questions or comment, as I like to
>> know I'm not just talking to myself here.
>>
>> And then maybe later next week, we might vote or come to some
>> other consensus that this is the right direction for Geronimo, and
>> well... then I'll make it become reality.
>>
>> Aighty, and now I'll shut up :-P
>>
>> --jason
>>
>>
>>
>> On Sep 8, 2007, at 11:53 AM, Jason Dillon wrote:
>>
>>> Aighty, well... I've done some long awaited re-factoring, and
>>> while its still not _perfect_ its a whole lot better now IMO I
>>> think from a framework perspective that its probably mature
>>> enough to take on the task of being the server bootloader.
>>>
>>> I'm going to continue to refactor the guts of GShell over time,
>>> of course... but I think that what is there now is highly usable
>>> for a simple platform independent launcher, as well as for
>>> porting over the other cli bits we have.
>>>
>>> I've done a lot of work in the past week, incase you didn't see
>>> the storm of scm messages... pulled out pico, plopped in plexus,
>>> pulled out commons-logging and commons-lang, which are suck and
>>> boated (in that order). I've gotten the basic framework and
>>> supported classes to use GShell down to ~ 1mb (a wee bit
>>> under)... though when I started to add the layout.xml abstraction
>>> stuff, I had to pull in xstream which bloated her back up to
>>> ~1.4m. I may eventually fix that... or not, cause xstream is
>>> soooo very handy for xml -> object stuff.
>>>
>>> I've fallen in love with annotations... they are *ucking great.
>>> They work really well for handling the cli option and argument
>>> muck which most every command needs to do. And striping out the
>>> insano-sucking commons-cli really simplified command
>>> implementations dramatically IMO.
>>>
>>> Anyways... I've make a heck of a lot of progress on cleaning up
>>> the GShell framework... and more is to come I'm sure... But for
>>> now, I think its probably ready for use primetime as the Geronimo
>>> Server's bootloader.
>>>
>>> I think this provides a some significant value...
>>>
>>> 1) Platform scripts become consistent and relatively simple, easy
>>> to maintain
>>>
>>> 2) Everyone will now have a consist way of launching the server,
>>> even if you like a .sh, .bat, or java -jar, then end process that
>>> is launched will be the same for everyone.
>>>
>>> 3) Opens up the door for some really nice and fancy fancy
>>> management muck (like restarting the server from the web console,
>>> or cloning a server instance or backing up a server instance...)
>>>
>>> 4) Lays the ground work for future features, like cluster
>>> management, remote administration and scripting...
>>>
>>> * * *
>>>
>>> So, I think its time to decide... are we a go or no go for GShell
>>> as the core CLI for Geronimo thingys and even more important, are
>>> we go or no go for using GShell to boot up the server process?
>>>
>>> --jason
>>>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jeff Genender <jg...@savoirtech.com>.
Is this working for the Tomcat assembly? If not...can it soon?
Thanks,
Jeff
Sent from my iPhone
On Sep 8, 2007, at 1:40 PM, Jason Dillon <ja...@planet57.com> wrote:
> A little bit more insight into what I'm thinking of doing... since
> some of you can't read minds to well :-P
>
> I'd like to convert all of the assemblies to basically look like
> what the assemblies/geronimo-jetty6-javaee5-gshell produces.
>
> And then I'd like to start converting the other cli bits to gshell
> command impls, like: deployer, client and shutdown.
>
> And then (maybe around the same time or before the above), I'd like
> to adapt the gshell of target jvm bits to load jars from the
> repository, instead of using the lib/* bits.
>
> A little background for those who haven't looked at assemblies/
> geronimo-jetty6-javaee5-gshell and what it produces from a lib/*
> perspective. Right now I've set up the assembly to produce:
>
> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib
> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot
> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed
> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell
>
> Where the bits in lib/* and lib/endorsed/* are the same as they were
> before. The bits in lib/boot/* and lib/gshell/* are specific to
> gshell. And normally a gshell installation would have everything I
> put into lib/gshell/* into lib/*, but I moved them to a sub dir for
> now... since the bin/*.jar's load jars from the ../lib/* dirs.
>
> The lib/boot/* stuff is the very minimal gshell bootstrap classes,
> which setup up the other happiness... and let you do things like:
>
> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/
> gshell-bootstrap.jar
>
> And that will give you a nice shell... or
>
> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/
> gshell-bootstrap.jar start-server
>
> That will launch the G server process using all of the right -
> Djava.ext.dirs and whatever properties that we currently have hacked
> into platform scripts.
>
> Anyways, so the idea is to move all of the bits which are current in
> the lib/* into the repository, and then configure the gshell command
> impl to load put the correct dependency artifacts onto the classpath
> of the target jvm that is booted up. This will augment the existing
> kernel bootstrap from repo stuff, putting evertying except what is
> needed from gshell into the repository...
>
> And really, what I'd like to eventually get to is having the
> bootstrap from the repository... so that everything except for what
> is now it lib/boot/* and lib/endorsed/* can live in the repository
> like happy little communistic jars should be :-P
>
> * * *
>
> And then there are longer term things for GShell...
>
> Remote administration (via, telnet, ssh, or custom ssl protocol...
> last is most likely to actually happen soonish)
>
> Process management, which is great for clusters, or staging ->
> production management. A full suite of command-line tools which can
> manage the configuration of a server... easily. So, for example,
> lets say you've got a configuration that is working really well for
> you... but you want to play with something new...
>
> So you might:
>
> ./bin/gsh backup-configuration before-mucking
> ./bin/gsh start-server
>
> And then go and change a whole bunch of stuff... and it doesn't
> work... yikes... so rollback...
>
> ./bin/gsh backup-configuration hosed-server
> ./bin/gsh restore-configuration before-mucking
> ./bin/gsh start-server
>
> And then maybe you want to play with the "hosed-server"
> configuration again...
>
> ./bin/gsh start-server --configuration hosed-server
>
> Of course, all of these could have been run from a single ./bin/gsh,
> but just for clarity, you can run them one off too.
>
> Maybe list or mange the configurations
>
> ./bin/gsh list-configurations
> ./bin/gsh remove-configuration some-unwanted-config
> ./bin/gsh copy-configuration default some-new-config
>
> The sky is the limit really... for what kind of management we can
> do...
>
> Lets say you wanted to do the above on a remote node?
>
> ./bin/gsh remote-shell someserver:9443
> Connecting to someserver:9447...
> Connected
>
> username: system
> password: **** (remember this is all jline, so we can mask
> passwords like one woudl expect)
>
> someserver:9447 > list-configurations
> someserver:9447 > remove-configuration some-unwanted-config
> someserver:9447 > copy-configuration default some-new-config
>
> So, all of these operations would happen on the node named
> "someserver" listening on 9443 (over ssl of course). Or how about
> you want to reboot a server remotely?
>
> someserver:9447 > restart-server now
> Geronimo server shutting down...
> ....
> Geronimo server shutdown.
> Geronimo server starting...
> ...
> Geronimo server started in ...
>
> Since GShell manages the processes its really easy to perform a full
> restart of a Server w/o needing magical platform scripting muck.
> And it will just work the same on each platform too.
>
> Once we have clustering, then we can do the same kinda thing for an
> entire cluster of nodes...
>
> someserver:9447 > restart-cluster now
> Shutting down 2 nodes...
> <node1> Geronimo server shutting down...
> <node1>....
> <node2> Geronimo server shutting down...
> <node2>....
> <node1>Geronimo server shutdown.
> <node2>Geronimo server shutdown.
> Starting up 2 nodes...
> <node1>Geronimo server starting...
> <node1>..
> <node2>Geronimo server starting...
> <node2>..
> <node1>Geronimo server started in ...
> <node2>Geronimo server started in ...
> Started up 2 nodes.
>
> And well, if you had some kinda script file which controlled say a
> logical grouping of nodes you could easily invoke that script (ya
> even on a remote system) and it will go and do it:
>
> someserver:9447 > script -l groovy local:file://restart-
> universe.groovy qa-universe
>
> The local: bit of the uri siginals the local URL handler to be used,
> which will cause the file://restart-universe.groovy to be loaded
> from the gsh instance where you are actually logged into (and ran
> the remote-shell gshell command) and will pipe its contents securely
> to the remote shell running on someserver:9447 and pass it to the
> script command to execute.
>
> The restart-universe.groovy might look something like this:
>
> <snip>
> import universe.Lookup
>
> assert args.size == 1 : 'Missing universe name'
>
> def universe = args[0]
>
> // Look up a list of nodes (for now say they are basically
> hostname:port)
> def nodes = Lookup.lookup(universe)
>
> log.info("Stopping universe ${universe}...")
> nodes.each { host ->
> shell.execute("remove-shell $host stop-server")
> }
> log.info("Universe ${universe} stopped")
>
> log.info("Starting universe ${universe}...")
> nodes.each { host ->
> shell.execute("remove-shell $host start-server")
> }
> log.info("Universe ${universe} started")
> </snip>
>
> Its kinda crude script, but I think you get the general point...
>
> * * *
>
> Anyways... I see... well, *HUGE* potential for this stuff...
>
> And really, a lot of what I just described above isn't that far into
> fantasy, its all relatively easy to implement on top of GShell... as
> it is now (or really as it was a year+ ago when I wrote it). Its
> really a matter of do others see the same value... and do others see
> the vision of using GShell as the core process launcher to allow
> things like "restart-server", or a "stop-server; copy-configuration
> default known-good; copy-configuration default testing; start-
> server", or that uber-fancy remote-shell muck.
>
> So, I'm gonna give y'all a few days to grok (or try to) what I've
> just spit out... please ask questions or comment, as I like to know
> I'm not just talking to myself here.
>
> And then maybe later next week, we might vote or come to some other
> consensus that this is the right direction for Geronimo, and well...
> then I'll make it become reality.
>
> Aighty, and now I'll shut up :-P
>
> --jason
>
>
>
> On Sep 8, 2007, at 11:53 AM, Jason Dillon wrote:
>
>> Aighty, well... I've done some long awaited re-factoring, and while
>> its still not _perfect_ its a whole lot better now IMO I think
>> from a framework perspective that its probably mature enough to
>> take on the task of being the server bootloader.
>>
>> I'm going to continue to refactor the guts of GShell over time, of
>> course... but I think that what is there now is highly usable for a
>> simple platform independent launcher, as well as for porting over
>> the other cli bits we have.
>>
>> I've done a lot of work in the past week, incase you didn't see the
>> storm of scm messages... pulled out pico, plopped in plexus, pulled
>> out commons-logging and commons-lang, which are suck and boated (in
>> that order). I've gotten the basic framework and supported classes
>> to use GShell down to ~ 1mb (a wee bit under)... though when I
>> started to add the layout.xml abstraction stuff, I had to pull in
>> xstream which bloated her back up to ~1.4m. I may eventually fix
>> that... or not, cause xstream is soooo very handy for xml -> object
>> stuff.
>>
>> I've fallen in love with annotations... they are *ucking great.
>> They work really well for handling the cli option and argument muck
>> which most every command needs to do. And striping out the insano-
>> sucking commons-cli really simplified command implementations
>> dramatically IMO.
>>
>> Anyways... I've make a heck of a lot of progress on cleaning up the
>> GShell framework... and more is to come I'm sure... But for now, I
>> think its probably ready for use primetime as the Geronimo Server's
>> bootloader.
>>
>> I think this provides a some significant value...
>>
>> 1) Platform scripts become consistent and relatively simple, easy
>> to maintain
>>
>> 2) Everyone will now have a consist way of launching the server,
>> even if you like a .sh, .bat, or java -jar, then end process that
>> is launched will be the same for everyone.
>>
>> 3) Opens up the door for some really nice and fancy fancy
>> management muck (like restarting the server from the web console,
>> or cloning a server instance or backing up a server instance...)
>>
>> 4) Lays the ground work for future features, like cluster
>> management, remote administration and scripting...
>>
>> * * *
>>
>> So, I think its time to decide... are we a go or no go for GShell
>> as the core CLI for Geronimo thingys and even more important, are
>> we go or no go for using GShell to boot up the server process?
>>
>> --jason
>>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jason Dillon <ja...@planet57.com>.
On Sep 10, 2007, at 7:18 AM, Paul McMahan wrote:
> This is really cool stuff, I'm pretty blown away. I'm convinced
> that a significant percentage of app server administrators prefer a
> power scripting interface over a fancy UI, so now Geronimo can
> offer both.
Um, ya... well at least those with some skillz. I'm sure those used
to Winblows might still prefer "click-click-click..." :-P
> I seem to recall some discussion about supporting multiple
> scripting languages.. but I can't find anything in the dev archives
> though so maybe I am imagining that? Either way, I think groovy
> is certainly adequate.
Um, well... the 'script' command I wrote like a year ago uses BSF so
you can run any scripting language that is supported by it...
assuming you include the required jars for the language's engine.
And of course, you can write commands in whatever you wish, just as
long as the end result is a java .class which implements the right
interface so that the shell can load it.
* * *
Oh, and here is a little taste of what the shell looks like now after
I've massaged it over the last few weeks...
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Paul McMahan <pa...@gmail.com>.
This is really cool stuff, I'm pretty blown away. I'm convinced
that a significant percentage of app server administrators prefer a
power scripting interface over a fancy UI, so now Geronimo can offer
both. I seem to recall some discussion about supporting multiple
scripting languages.. but I can't find anything in the dev archives
though so maybe I am imagining that? Either way, I think groovy is
certainly adequate.
Best wishes,
Paul
On Sep 8, 2007, at 3:40 PM, Jason Dillon wrote:
> A little bit more insight into what I'm thinking of doing... since
> some of you can't read minds to well :-P
>
> I'd like to convert all of the assemblies to basically look like
> what the assemblies/geronimo-jetty6-javaee5-gshell produces.
>
> And then I'd like to start converting the other cli bits to gshell
> command impls, like: deployer, client and shutdown.
>
> And then (maybe around the same time or before the above), I'd like
> to adapt the gshell of target jvm bits to load jars from the
> repository, instead of using the lib/* bits.
>
> A little background for those who haven't looked at assemblies/
> geronimo-jetty6-javaee5-gshell and what it produces from a lib/*
> perspective. Right now I've set up the assembly to produce:
>
> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib
> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot
> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed
> geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell
>
> Where the bits in lib/* and lib/endorsed/* are the same as they
> were before. The bits in lib/boot/* and lib/gshell/* are specific
> to gshell. And normally a gshell installation would have
> everything I put into lib/gshell/* into lib/*, but I moved them to
> a sub dir for now... since the bin/*.jar's load jars from the ../
> lib/* dirs.
>
> The lib/boot/* stuff is the very minimal gshell bootstrap classes,
> which setup up the other happiness... and let you do things like:
>
> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
> boot/gshell-bootstrap.jar
>
> And that will give you a nice shell... or
>
> java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/
> boot/gshell-bootstrap.jar start-server
>
> That will launch the G server process using all of the right -
> Djava.ext.dirs and whatever properties that we currently have
> hacked into platform scripts.
>
> Anyways, so the idea is to move all of the bits which are current
> in the lib/* into the repository, and then configure the gshell
> command impl to load put the correct dependency artifacts onto the
> classpath of the target jvm that is booted up. This will augment
> the existing kernel bootstrap from repo stuff, putting evertying
> except what is needed from gshell into the repository...
>
> And really, what I'd like to eventually get to is having the
> bootstrap from the repository... so that everything except for what
> is now it lib/boot/* and lib/endorsed/* can live in the repository
> like happy little communistic jars should be :-P
>
> * * *
>
> And then there are longer term things for GShell...
>
> Remote administration (via, telnet, ssh, or custom ssl protocol...
> last is most likely to actually happen soonish)
>
> Process management, which is great for clusters, or staging ->
> production management. A full suite of command-line tools which
> can manage the configuration of a server... easily. So, for
> example, lets say you've got a configuration that is working really
> well for you... but you want to play with something new...
>
> So you might:
>
> ./bin/gsh backup-configuration before-mucking
> ./bin/gsh start-server
>
> And then go and change a whole bunch of stuff... and it doesn't
> work... yikes... so rollback...
>
> ./bin/gsh backup-configuration hosed-server
> ./bin/gsh restore-configuration before-mucking
> ./bin/gsh start-server
>
> And then maybe you want to play with the "hosed-server"
> configuration again...
>
> ./bin/gsh start-server --configuration hosed-server
>
> Of course, all of these could have been run from a single ./bin/
> gsh, but just for clarity, you can run them one off too.
>
> Maybe list or mange the configurations
>
> ./bin/gsh list-configurations
> ./bin/gsh remove-configuration some-unwanted-config
> ./bin/gsh copy-configuration default some-new-config
>
> The sky is the limit really... for what kind of management we can
> do...
>
> Lets say you wanted to do the above on a remote node?
>
> ./bin/gsh remote-shell someserver:9443
> Connecting to someserver:9447...
> Connected
>
> username: system
> password: **** (remember this is all jline, so we can mask
> passwords like one woudl expect)
>
> someserver:9447 > list-configurations
> someserver:9447 > remove-configuration some-unwanted-config
> someserver:9447 > copy-configuration default some-new-config
>
> So, all of these operations would happen on the node named
> "someserver" listening on 9443 (over ssl of course). Or how about
> you want to reboot a server remotely?
>
> someserver:9447 > restart-server now
> Geronimo server shutting down...
> ....
> Geronimo server shutdown.
> Geronimo server starting...
> ...
> Geronimo server started in ...
>
> Since GShell manages the processes its really easy to perform a
> full restart of a Server w/o needing magical platform scripting
> muck. And it will just work the same on each platform too.
>
> Once we have clustering, then we can do the same kinda thing for an
> entire cluster of nodes...
>
> someserver:9447 > restart-cluster now
> Shutting down 2 nodes...
> <node1> Geronimo server shutting down...
> <node1>....
> <node2> Geronimo server shutting down...
> <node2>....
> <node1>Geronimo server shutdown.
> <node2>Geronimo server shutdown.
> Starting up 2 nodes...
> <node1>Geronimo server starting...
> <node1>..
> <node2>Geronimo server starting...
> <node2>..
> <node1>Geronimo server started in ...
> <node2>Geronimo server started in ...
> Started up 2 nodes.
>
> And well, if you had some kinda script file which controlled say a
> logical grouping of nodes you could easily invoke that script (ya
> even on a remote system) and it will go and do it:
>
> someserver:9447 > script -l groovy local:file://restart-
> universe.groovy qa-universe
>
> The local: bit of the uri siginals the local URL handler to be
> used, which will cause the file://restart-universe.groovy to be
> loaded from the gsh instance where you are actually logged into
> (and ran the remote-shell gshell command) and will pipe its
> contents securely to the remote shell running on someserver:9447
> and pass it to the script command to execute.
>
> The restart-universe.groovy might look something like this:
>
> <snip>
> import universe.Lookup
>
> assert args.size == 1 : 'Missing universe name'
>
> def universe = args[0]
>
> // Look up a list of nodes (for now say they are basically
> hostname:port)
> def nodes = Lookup.lookup(universe)
>
> log.info("Stopping universe ${universe}...")
> nodes.each { host ->
> shell.execute("remove-shell $host stop-server")
> }
> log.info("Universe ${universe} stopped")
>
> log.info("Starting universe ${universe}...")
> nodes.each { host ->
> shell.execute("remove-shell $host start-server")
> }
> log.info("Universe ${universe} started")
> </snip>
>
> Its kinda crude script, but I think you get the general point...
>
> * * *
>
> Anyways... I see... well, *HUGE* potential for this stuff...
>
> And really, a lot of what I just described above isn't that far
> into fantasy, its all relatively easy to implement on top of
> GShell... as it is now (or really as it was a year+ ago when I
> wrote it). Its really a matter of do others see the same value...
> and do others see the vision of using GShell as the core process
> launcher to allow things like "restart-server", or a "stop-server;
> copy-configuration default known-good; copy-configuration default
> testing; start-server", or that uber-fancy remote-shell muck.
>
> So, I'm gonna give y'all a few days to grok (or try to) what I've
> just spit out... please ask questions or comment, as I like to know
> I'm not just talking to myself here.
>
> And then maybe later next week, we might vote or come to some other
> consensus that this is the right direction for Geronimo, and
> well... then I'll make it become reality.
>
> Aighty, and now I'll shut up :-P
>
> --jason
>
>
>
> On Sep 8, 2007, at 11:53 AM, Jason Dillon wrote:
>
>> Aighty, well... I've done some long awaited re-factoring, and
>> while its still not _perfect_ its a whole lot better now IMO I
>> think from a framework perspective that its probably mature enough
>> to take on the task of being the server bootloader.
>>
>> I'm going to continue to refactor the guts of GShell over time, of
>> course... but I think that what is there now is highly usable for
>> a simple platform independent launcher, as well as for porting
>> over the other cli bits we have.
>>
>> I've done a lot of work in the past week, incase you didn't see
>> the storm of scm messages... pulled out pico, plopped in plexus,
>> pulled out commons-logging and commons-lang, which are suck and
>> boated (in that order). I've gotten the basic framework and
>> supported classes to use GShell down to ~ 1mb (a wee bit under)...
>> though when I started to add the layout.xml abstraction stuff, I
>> had to pull in xstream which bloated her back up to ~1.4m. I may
>> eventually fix that... or not, cause xstream is soooo very handy
>> for xml -> object stuff.
>>
>> I've fallen in love with annotations... they are *ucking great.
>> They work really well for handling the cli option and argument
>> muck which most every command needs to do. And striping out the
>> insano-sucking commons-cli really simplified command
>> implementations dramatically IMO.
>>
>> Anyways... I've make a heck of a lot of progress on cleaning up
>> the GShell framework... and more is to come I'm sure... But for
>> now, I think its probably ready for use primetime as the Geronimo
>> Server's bootloader.
>>
>> I think this provides a some significant value...
>>
>> 1) Platform scripts become consistent and relatively simple, easy
>> to maintain
>>
>> 2) Everyone will now have a consist way of launching the server,
>> even if you like a .sh, .bat, or java -jar, then end process that
>> is launched will be the same for everyone.
>>
>> 3) Opens up the door for some really nice and fancy fancy
>> management muck (like restarting the server from the web console,
>> or cloning a server instance or backing up a server instance...)
>>
>> 4) Lays the ground work for future features, like cluster
>> management, remote administration and scripting...
>>
>> * * *
>>
>> So, I think its time to decide... are we a go or no go for GShell
>> as the core CLI for Geronimo thingys and even more important, are
>> we go or no go for using GShell to boot up the server process?
>>
>> --jason
>>
>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jason Dillon <ja...@planet57.com>.
A little bit more insight into what I'm thinking of doing... since
some of you can't read minds to well :-P
I'd like to convert all of the assemblies to basically look like what
the assemblies/geronimo-jetty6-javaee5-gshell produces.
And then I'd like to start converting the other cli bits to gshell
command impls, like: deployer, client and shutdown.
And then (maybe around the same time or before the above), I'd like
to adapt the gshell of target jvm bits to load jars from the
repository, instead of using the lib/* bits.
A little background for those who haven't looked at assemblies/
geronimo-jetty6-javaee5-gshell and what it produces from a lib/*
perspective. Right now I've set up the assembly to produce:
geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib
geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot
geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed
geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell
Where the bits in lib/* and lib/endorsed/* are the same as they were
before. The bits in lib/boot/* and lib/gshell/* are specific to
gshell. And normally a gshell installation would have everything I
put into lib/gshell/* into lib/*, but I moved them to a sub dir for
now... since the bin/*.jar's load jars from the ../lib/* dirs.
The lib/boot/* stuff is the very minimal gshell bootstrap classes,
which setup up the other happiness... and let you do things like:
java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/
gshell-bootstrap.jar
And that will give you a nice shell... or
java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/
gshell-bootstrap.jar start-server
That will launch the G server process using all of the right -
Djava.ext.dirs and whatever properties that we currently have hacked
into platform scripts.
Anyways, so the idea is to move all of the bits which are current in
the lib/* into the repository, and then configure the gshell command
impl to load put the correct dependency artifacts onto the classpath
of the target jvm that is booted up. This will augment the existing
kernel bootstrap from repo stuff, putting evertying except what is
needed from gshell into the repository...
And really, what I'd like to eventually get to is having the
bootstrap from the repository... so that everything except for what
is now it lib/boot/* and lib/endorsed/* can live in the repository
like happy little communistic jars should be :-P
* * *
And then there are longer term things for GShell...
Remote administration (via, telnet, ssh, or custom ssl protocol...
last is most likely to actually happen soonish)
Process management, which is great for clusters, or staging ->
production management. A full suite of command-line tools which can
manage the configuration of a server... easily. So, for example,
lets say you've got a configuration that is working really well for
you... but you want to play with something new...
So you might:
./bin/gsh backup-configuration before-mucking
./bin/gsh start-server
And then go and change a whole bunch of stuff... and it doesn't
work... yikes... so rollback...
./bin/gsh backup-configuration hosed-server
./bin/gsh restore-configuration before-mucking
./bin/gsh start-server
And then maybe you want to play with the "hosed-server" configuration
again...
./bin/gsh start-server --configuration hosed-server
Of course, all of these could have been run from a single ./bin/gsh,
but just for clarity, you can run them one off too.
Maybe list or mange the configurations
./bin/gsh list-configurations
./bin/gsh remove-configuration some-unwanted-config
./bin/gsh copy-configuration default some-new-config
The sky is the limit really... for what kind of management we can do...
Lets say you wanted to do the above on a remote node?
./bin/gsh remote-shell someserver:9443
Connecting to someserver:9447...
Connected
username: system
password: **** (remember this is all jline, so we can mask
passwords like one woudl expect)
someserver:9447 > list-configurations
someserver:9447 > remove-configuration some-unwanted-config
someserver:9447 > copy-configuration default some-new-config
So, all of these operations would happen on the node named
"someserver" listening on 9443 (over ssl of course). Or how about
you want to reboot a server remotely?
someserver:9447 > restart-server now
Geronimo server shutting down...
....
Geronimo server shutdown.
Geronimo server starting...
...
Geronimo server started in ...
Since GShell manages the processes its really easy to perform a full
restart of a Server w/o needing magical platform scripting muck. And
it will just work the same on each platform too.
Once we have clustering, then we can do the same kinda thing for an
entire cluster of nodes...
someserver:9447 > restart-cluster now
Shutting down 2 nodes...
<node1> Geronimo server shutting down...
<node1>....
<node2> Geronimo server shutting down...
<node2>....
<node1>Geronimo server shutdown.
<node2>Geronimo server shutdown.
Starting up 2 nodes...
<node1>Geronimo server starting...
<node1>..
<node2>Geronimo server starting...
<node2>..
<node1>Geronimo server started in ...
<node2>Geronimo server started in ...
Started up 2 nodes.
And well, if you had some kinda script file which controlled say a
logical grouping of nodes you could easily invoke that script (ya
even on a remote system) and it will go and do it:
someserver:9447 > script -l groovy local:file://restart-
universe.groovy qa-universe
The local: bit of the uri siginals the local URL handler to be used,
which will cause the file://restart-universe.groovy to be loaded from
the gsh instance where you are actually logged into (and ran the
remote-shell gshell command) and will pipe its contents securely to
the remote shell running on someserver:9447 and pass it to the script
command to execute.
The restart-universe.groovy might look something like this:
<snip>
import universe.Lookup
assert args.size == 1 : 'Missing universe name'
def universe = args[0]
// Look up a list of nodes (for now say they are basically
hostname:port)
def nodes = Lookup.lookup(universe)
log.info("Stopping universe ${universe}...")
nodes.each { host ->
shell.execute("remove-shell $host stop-server")
}
log.info("Universe ${universe} stopped")
log.info("Starting universe ${universe}...")
nodes.each { host ->
shell.execute("remove-shell $host start-server")
}
log.info("Universe ${universe} started")
</snip>
Its kinda crude script, but I think you get the general point...
* * *
Anyways... I see... well, *HUGE* potential for this stuff...
And really, a lot of what I just described above isn't that far into
fantasy, its all relatively easy to implement on top of GShell... as
it is now (or really as it was a year+ ago when I wrote it). Its
really a matter of do others see the same value... and do others see
the vision of using GShell as the core process launcher to allow
things like "restart-server", or a "stop-server; copy-configuration
default known-good; copy-configuration default testing; start-
server", or that uber-fancy remote-shell muck.
So, I'm gonna give y'all a few days to grok (or try to) what I've
just spit out... please ask questions or comment, as I like to know
I'm not just talking to myself here.
And then maybe later next week, we might vote or come to some other
consensus that this is the right direction for Geronimo, and well...
then I'll make it become reality.
Aighty, and now I'll shut up :-P
--jason
On Sep 8, 2007, at 11:53 AM, Jason Dillon wrote:
> Aighty, well... I've done some long awaited re-factoring, and while
> its still not _perfect_ its a whole lot better now IMO I think
> from a framework perspective that its probably mature enough to
> take on the task of being the server bootloader.
>
> I'm going to continue to refactor the guts of GShell over time, of
> course... but I think that what is there now is highly usable for a
> simple platform independent launcher, as well as for porting over
> the other cli bits we have.
>
> I've done a lot of work in the past week, incase you didn't see the
> storm of scm messages... pulled out pico, plopped in plexus, pulled
> out commons-logging and commons-lang, which are suck and boated (in
> that order). I've gotten the basic framework and supported classes
> to use GShell down to ~ 1mb (a wee bit under)... though when I
> started to add the layout.xml abstraction stuff, I had to pull in
> xstream which bloated her back up to ~1.4m. I may eventually fix
> that... or not, cause xstream is soooo very handy for xml -> object
> stuff.
>
> I've fallen in love with annotations... they are *ucking great.
> They work really well for handling the cli option and argument muck
> which most every command needs to do. And striping out the insano-
> sucking commons-cli really simplified command implementations
> dramatically IMO.
>
> Anyways... I've make a heck of a lot of progress on cleaning up the
> GShell framework... and more is to come I'm sure... But for now, I
> think its probably ready for use primetime as the Geronimo Server's
> bootloader.
>
> I think this provides a some significant value...
>
> 1) Platform scripts become consistent and relatively simple, easy
> to maintain
>
> 2) Everyone will now have a consist way of launching the server,
> even if you like a .sh, .bat, or java -jar, then end process that
> is launched will be the same for everyone.
>
> 3) Opens up the door for some really nice and fancy fancy
> management muck (like restarting the server from the web console,
> or cloning a server instance or backing up a server instance...)
>
> 4) Lays the ground work for future features, like cluster
> management, remote administration and scripting...
>
> * * *
>
> So, I think its time to decide... are we a go or no go for GShell
> as the core CLI for Geronimo thingys and even more important, are
> we go or no go for using GShell to boot up the server process?
>
> --jason
>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jason Dillon <ja...@planet57.com>.
Aighty, well... I've done some long awaited re-factoring, and while
its still not _perfect_ its a whole lot better now IMO I think from
a framework perspective that its probably mature enough to take on
the task of being the server bootloader.
I'm going to continue to refactor the guts of GShell over time, of
course... but I think that what is there now is highly usable for a
simple platform independent launcher, as well as for porting over the
other cli bits we have.
I've done a lot of work in the past week, incase you didn't see the
storm of scm messages... pulled out pico, plopped in plexus, pulled
out commons-logging and commons-lang, which are suck and boated (in
that order). I've gotten the basic framework and supported classes
to use GShell down to ~ 1mb (a wee bit under)... though when I
started to add the layout.xml abstraction stuff, I had to pull in
xstream which bloated her back up to ~1.4m. I may eventually fix
that... or not, cause xstream is soooo very handy for xml -> object
stuff.
I've fallen in love with annotations... they are *ucking great. They
work really well for handling the cli option and argument muck which
most every command needs to do. And striping out the insano-sucking
commons-cli really simplified command implementations dramatically IMO.
Anyways... I've make a heck of a lot of progress on cleaning up the
GShell framework... and more is to come I'm sure... But for now, I
think its probably ready for use primetime as the Geronimo Server's
bootloader.
I think this provides a some significant value...
1) Platform scripts become consistent and relatively simple, easy
to maintain
2) Everyone will now have a consist way of launching the server,
even if you like a .sh, .bat, or java -jar, then end process that is
launched will be the same for everyone.
3) Opens up the door for some really nice and fancy fancy
management muck (like restarting the server from the web console, or
cloning a server instance or backing up a server instance...)
4) Lays the ground work for future features, like cluster
management, remote administration and scripting...
* * *
So, I think its time to decide... are we a go or no go for GShell as
the core CLI for Geronimo thingys and even more important, are we go
or no go for using GShell to boot up the server process?
--jason
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by "Erik B. Craig" <gi...@gmail.com>.
Oh man,
Gshell is looking to be pretty sweet, awesome work Jason.
One thing that would definitely be cool is implementing SSH into it, and I
did notice there's already a Jira for that, I'm sure I can brainstorm up a
few other additions given time... want a little help on the side? =)
On 8/21/07, Jason Dillon <ja...@planet57.com> 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
>
>
>
>
--
Erik B. Craig
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jason Dillon <ja...@planet57.com>.
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 :-(
Ya, I am aware of the very, very, very sad and unfortunate fact...
those poor users. Anyways, GShell should help us build more portable
fluff for them, since we can code the platform specifics directly in
Java.
I'm not sure what the above exception is from, I'll fire up a build
on my windows system and see what it pukes up.
--jason
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jason Dillon <ja...@planet57.com>.
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 <ja...@planet57.com> 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
>>
>>
>>
>>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Prasad Kashyap <go...@gmail.com>.
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 <ja...@planet57.com> 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
>
>
>
>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jason Dillon <ja...@planet57.com>.
On Aug 21, 2007, at 11:40 PM, David Jencks wrote:
> I played around with this a little bit and really like it.
Yay! Thanks for taking a look David!
> 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.
I plan to make GShell commands for all of the above soon, was just
waiting for folks to take a look at the start-server bits I added as
a POC and get feedback before I dive into all the other commands.
Though you can still run the existing scripts to use those tools, but
ya I do plan on adding them as GShell commands soon ;-)
> - easy way to debug, setting the port and suspend, perhaps again
> with 'env vars"
Yup, we can add any flags to 'start-server' which help make life
easier... probably need to get those bits from the geronimo.sh script
ported over too, 'jpda, start, stop, run, etc'.
You can current do stuff like this in the shell:
> set debug_flags=foo
And then commands have that context passed in... but so far, except
for the 'set' and 'unset' commands no commands use that context yet.
There is also a evil bug in the current parser that freaks out on
quotes... which I hope to get fixed soon.
> - 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
I've added a -G flag... so -Gfoo=bar is the same as -
Dorg.apache.geronimo.foo=bar. We can sort out all of the nice short-
hand flags over time... ;-) But keep the ideas coming for sure...
cause I'm not sure how folks actually use this stuff ;-)
> 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.
Yup, right now... I think... you can 'start-server --background' and
it will wait for the server to boot, then return you to a shell and
server output will still be put on console, unless you used 'start-
server --logfile /foo/bar' or something. But I eventually want to
get this syntax working for the same thing:
start-server &
But that requires more parser hacking... so, its a feature planned
on, but pending someone to help me with the grammar and ast mucko ;-)
> I'm looking forward to this developing more features :-)
Yay! I'm starting to become more interested in making GShell rule
the world again too ;-)
Cheers,
--jason
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by David Jencks <da...@yahoo.com>.
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
>>
>>
>>
>
Re: New GShell-based Geronimo Server launcher now in server/trunk
Posted by Jason Dillon <ja...@planet57.com>.
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
>
>
>