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/10/01 09:25:04 UTC
Porting the cli deployer/geronimo-cli bits to GShell
Um... anyone fancy a stab at porting the deployer/geronimo-cli bits
to GShell commands? It shouldn't be too much work, probably will
facilitate cleaning a lot of that stuff up. But might need a bit of
help to get the classloading magic right er something.
Its been on my list for a while... I just converted the shutdown, but
that was um... uber-trivial so I don't even count that as work really.
But is there anyone out there that might want a taste of GShell? I
could use a hand...
Thanks,
--jason
Re: Porting the cli deployer/geronimo-cli bits to GShell
Posted by Jason Dillon <ja...@planet57.com>.
Oh, and one more thing (last time really)...
If you are feeling adventurous you can grab one of the assemblies...
like:
http://tinyurl.com/2xn7bm (tar.gz)
or:
http://tinyurl.com/29zx4w (zip)
--jason
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:
>
> http://geronimo.apache.org/maven/gshell/
>
> (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:
>
> http://geronimo.apache.org/maven/gshell/apidocs/index.html
>
> --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 <ja...@planet57.com> 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
>>
>
Re: Porting the cli deployer/geronimo-cli bits to GShell
Posted by Jason Dillon <ja...@planet57.com>.
One more thing.... I published snaps earlier today and just pushed
out the latest site, which you can see here:
http://geronimo.apache.org/maven/gshell/
(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:
http://geronimo.apache.org/maven/gshell/apidocs/index.html
--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 <ja...@planet57.com> 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
>
Re: Porting the cli deployer/geronimo-cli bits to GShell
Posted by Jason Dillon <ja...@planet57.com>.
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 <ja...@planet57.com> 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
Re: Porting the cli deployer/geronimo-cli bits to GShell
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 10/1/07, Jason Dillon <ja...@planet57.com> 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