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 <[EMAIL PROTECTED]> 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
http://www.JacekLaskowski.pl
