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:21:39 GMT
Oh, and one more thing (last time really)...

If you are feeling adventurous you can grab one of the assemblies...  
like: (tar.gz)

or: (zip)


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

> 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:
> --jason
> 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