geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Porting the cli deployer/geronimo-cli bits to GShell
Date Mon, 01 Oct 2007 09:07:43 GMT
Its *relatively* simple... just a matter of picking one of the easier  
commands that doesn't need a bunch of magically class-loading muck.

There are 2 command instances right now in the geronimo-commands  
module (start-server and stop-server).  To create a new command is  
very simple, simply create a new .java or .groovy (I'd go for .groovy  
right now) source in the tree, like say a 'list-modules' command:

import org.apache.geronimo.gshell.command.annotation.CommandComponent
import org.apache.geronimo.gshell.command.CommandSupport

  * List the running modules in a Geronimo server.
  * @version $Rev$ $Date$
class ListModulesCommand
	extends CommandSupport
     protected Object doExecute() throws Exception {
         io.out.println('Hello World')

         log.debug("This is our happy happy instance: {}", this)

         // TODO: Do something more useful

         return SUCCESS

You need to annotate the command with the @CommandComponent  
annotation and give it an ID, which for right now ends up being the  
command-name you'd execute in the shell.  Extend from CommandSupport  
to pick up some plumbing... and then implement doExecute().

You can peep at the StartServerCommand to see how annotations are  
used to handle command-line arguments and options.  The  
CommandSupport muck handles invoking the CLP (command-line processor)  
bits to detect the @Argument and @Option annotations and then inject  
the values accordingly.

CommandSupport also sets up the command's IO instance, which is  
basically just a container for input/output streams and their reader/ 
writer equivalents.  The 'io' instance is used to spit out just to  
the user, like:

     io.out.println('Hi there')

Which as you might guess is very similar to a System.out.println(),  
though the IO instance is used because the shell could be remote  
running over TCP+SSL or embedded in another shell, etc.

The @CommandComponent tells the gshell-maven-plugin to include that  
command-instance when generating the classes/META-INF/gshell/ 
commands.xml descriptor (which is very similar to a Plexus  
commands.xml or a Maven plugin.xml)... in that its auto-generated  
from meta-data and the shell knows how to dynamically discover new  
sets of commands by looking for META-INF/gshell/commands.xml resources.

Anyways, IMO the biggest thing right now is going to be figuring out  
which of the deployer.jar commands can be easily re-crafted as GShell  
commands w/o having to bring in a full Kernel or otherwise augmenting  
the shell's classpath.  Basically, anything that currently lives in  
lib/* or in lib/gshell/* can be easily accessed.  Other bits which  
require a repository and bootstrap kernel will require a bit more  
work for me to adapt and simplify for easier integration... but its  
defs on the list.

  * * *

I'm probably going to take a break from the GShell rsh/rsh-server  
bits for a little while to let all that stuff settle in my head (and  
hopefully get some other eyes on the codebase too... extra eyes are  
always helpful).  And I'd like to finish up and get the startup/ 
shutdown bits all integrated with GShell and then start to tackle the  
deployer and client cli bits which are remaining.

There are also lots of little bits here and there that need more  
attention.  Like for example, I've yet to configure the start-server  
or stop-server commands to allow command-line arguments/options to  
set the hostname, port, username, password bits.  That should be  
relatively simple and perhaps not a bad place to start to get your  
feet wet and learn about some more GShell (which will rule the world  
one of these days... I'm telling ya).

Aighty... I'll stop babbling now.  Please lemme know if you have any  
questions, comments, suggestions or otherwise.  I'm hoping to entice  
a few more folks to at least start looking over the codebase, asking  
questions or whatever.



On Oct 1, 2007, at 1:35 AM, Jacek Laskowski wrote:

> On 10/1/07, Jason Dillon <> wrote:
>> But is there anyone out there that might want a taste of GShell?  I
>> could use a hand...
> Be on irc tonight (CET) - I'd like to see how uber-trivial it is ;-)
> Others invited.
> Jacek
> -- 
> Jacek Laskowski

View raw message