felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [gogo] Advanced commands / console
Date Sat, 04 Jul 2009 06:22:59 GMT
Not necesserally sub-shells, but the scope concept is already part of gogo.
Each command already has a scope.  For example, the bundleContext
methods are defined in the "osgi" scope so you can access those using:

$ bundles

or

$ osgi:bundles

This allow disambiguating otherwise ambiguous commands.
Derek also fixed some bugs around that.

I'm not sure yet, but I think you might change the default scope using

$ SCOPE = osgi

Hven't tried that though.

On Fri, Jul 3, 2009 at 23:46, Richard S. Hall<heavy@ungoverned.org> wrote:
> On 7/3/09 12:10 PM, Guillaume Nodet wrote:
>>
>> I've checked in the prototype into gogo for further discussion.
>> See https://svn.apache.org/repos/asf/felix/trunk/gogo/gogo.commands/
>>
>
> Note, I renamed this to:
>
>    https://svn.apache.org/repos/asf/felix/trunk/gogo/commands/
>
> I realized that I had the naming incorrect, even though I changed it a
> couple of days ago.
>
>> I've also fixed the gogo parser a bit as to be slightly more leniant
>> when parsing the first argument (so that '/' or '-' could be part of
>> the first argument).
>>
>
> Are you imaging the Karaf "sub-shell" concept being part of Gogo? I cannot
> say I am a fan of that concept.
>
> -> richard
>
>> Feedback welcome !
>>
>> On Thu, Jul 2, 2009 at 08:24, Guillaume Nodet<gnodet@gmail.com>  wrote:
>>
>>>
>>> For Karaf, I've been working on a prototype to be able to support more
>>> powerful commands in gogo.
>>> The problem with the current way (i.e. one function == one method) is
>>> that it's quite difficult to
>>>  * display help for a command
>>>  * have optional arguments
>>> So what I've done, and this would also benefit Karaf, is based on what
>>> gshell is doing for commands.
>>> It's based on the following interfaces:
>>>
>>> public interface Action
>>> {
>>>    Object execute(CommandSession session) throws Exception;
>>> }
>>>
>>> @Retention(RetentionPolicy.RUNTIME)
>>> @Target({ElementType.TYPE})
>>> public @interface Command
>>> {
>>>    String scope();
>>>
>>>    String name();
>>>
>>>    String description() default "";
>>> }
>>>
>>> @Retention(RetentionPolicy.RUNTIME)
>>> @Target({ElementType.FIELD, ElementType.METHOD})
>>> public @interface Argument
>>> {
>>>    String name() default "VAL";
>>>
>>>    String description() default "";
>>>
>>>    boolean required() default false;
>>>
>>>    int index() default 0;
>>>
>>>    boolean multiValued() default false;
>>> }
>>>
>>> @Retention(RetentionPolicy.RUNTIME)
>>> @Target({ElementType.FIELD, ElementType.METHOD})
>>> public @interface Option
>>> {
>>>    String name();
>>>
>>>    String[] aliases() default {};
>>>
>>>    String description() default "";
>>>
>>>    boolean required() default false;
>>>
>>>    boolean multiValued() default false;
>>>
>>> }
>>>
>>>
>>> So a given command would look like:
>>>
>>> @Command(scope = "my", name = "action")
>>> public class MyAction implements Action {
>>>
>>>    @Option(name = "-s", aliases = { "--start" })
>>>    boolean start;
>>>
>>>   @Argument(name = "ids", required = true, multivalued = true)
>>>   List<Integer>  ids;
>>>
>>>   public Object execute(CommandSession session) {
>>>       ...
>>>   }
>>> }
>>>
>>>
>>> This action has to be wrapped inside a command (implementing the
>>> Function interface) and which will be able to create a new instance of
>>> the action, parse the arguments, populate it, and call it.
>>> In addition the wrapper will detect the use of "-h" or "--help"
>>> arguments and compute / display the help on the console if requested.
>>>
>>> Curerntly, what I've done is leveraging blueprint, so I have a custom
>>> namespace (same as we had in karaf/gshell)
>>>
>>>    <command-bundle
>>> xmlns="http://felix.apache.org/karaf/xmlns/gshell/v1.0.0">
>>>        <command name="osgi/list">
>>>            <action
>>> class="org.apache.felix.karaf.gshell.osgi.ListBundles">
>>>                <property name="blueprintListener"
>>> ref="blueprintListener"/>
>>>            </action>
>>>        </command>
>>>    </command-bundle>
>>>
>>> This will create a command and register it in the OSGi registry so
>>> that it will be available in the shell.
>>>
>>> I haven't implemented completers yet, but that's next on my todo list.
>>>
>>> So the question is: should this be part of gogo or do we keep that for
>>> karaf ?
>>> I have the same question for the console: I've started working on an
>>> advanced console (leveraging jline as we did in karaf / gshell).
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>>
>>
>>
>>
>>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message