karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Simpler karaf shell command/action definition
Date Wed, 09 May 2012 15:08:32 GMT
We currently either use the blueprint namespace or the AbstractCommand 
and a service definition to define commands. This has some shortcomings:
- The blueprint namespace definition is a bit verbose and at first I did 
not understand that actions in the xml can be injected like beans

     <command-bundle xmlns="http://karaf.apache.org/xmlns/shell/v1.1.0">
              <action class="org.apache.karaf.shell.commands.impl.WatchAction">
                 <property name="commandProcessor" ref="commandProcessor"/>
                 <ref component-id="commandCompleter" />

- The other way using AbstractCommand and a service def is even more 
verbose and exposes a lot of implementation details like the 

<bean id="commandCompleter" class="org.apache.karaf.shell.console.completer.CommandsCompleter"/>
             <entry key="osgi.command.scope" value="*"/>
             <entry key="osgi.command.function" value="help"/>
         <bean class="org.apache.karaf.shell.console.commands.BlueprintCommand">
             <property name="blueprintContainer" ref="blueprintContainer"/>
             <property name="blueprintConverter" ref="blueprintConverter"/>
             <property name="actionId" value="help"/>
             <property name="completers">
                     <bean class="org.apache.karaf.shell.console.completer.CommandNamesCompleter"/>

     <bean id="help" class="org.apache.karaf.shell.help.impl.HelpAction" activation="lazy"
         <property name="provider" ref="helpSystem"/>

So here is what I propose:

The first thing is to add a complerers property to the @Commands 
annotation. This is the last bit we need to make sure the annotations 
provide all metadata of an action.
Then the idea is to simply define the action as a blueprint bean and 
publish it as an OSGi service. We then have an extender that adapts 
these to the felix gogo commands.

So the blueprint code for the help example above would look like:
<service interface="org.apache.karaf.shell.commands.Action">
<bean id="help" class="org.apache.karaf.shell.help.impl.HelpAction" 
activation="lazy" scope="prototype">
<property name="provider" ref="helpSystem"/>

With the upcoming blueprint annotations we could simply annotate the 
Action class and need no blueprint code at all. The above style would 
also work much better with declarative services. If you look at the scr 
module in karaf you see how complicated it is till now to create a 
command in ds.

One problem with the aproach is of course that the Action has to be 
created per execution. So we need to find a good way to clone the Action 
object. To a degree this problem is already present int the current 

So what are the advantages:
- The user code only depends on some very few interfaces like Action and 
the annotations. AbstractCommand and similar are not needed anymore and 
the impls can be private
- The blueprint syntax is quite concise and does not need a special 
- Using BP annotations the syntax is even more concise as no xml is 
needed. This would not be possible with the current way

So what do you think?


Christian Schneider

Open Source Architect
Talend Application Integration Division http://www.talend.com

View raw message