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:18:22 GMT
One more thing.... I published snaps earlier today and just pushed  
out the latest site, which you can see here:

(Gonna take a wee bit for it to sync).

Its a typical empty looking Maven site, but has and aggregated  
Javadocs page here if you want to see what's there:


On Oct 1, 2007, at 2:07 AM, Jason Dillon wrote:

> 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:
> <snip>
> 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$
>  */
> @CommandComponent(id='list-modules')
> 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
>     }
> }
> </snip>
> 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.
> Cheers,
> --jason
> 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