karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Simpler karaf shell command/action definition
Date Fri, 11 May 2012 07:03:49 GMT
Hi Guillaume,

I know that our Action model requires that the Action is stateful and 
has to be created per exceution of the command. So I dont really want to 
change that.
The idea is to publish the Action as a kind of factory.

So we could either use reflection to clone the Action from the service 
or what might be cleaner to provide a clone method. I provided a small 
example below that
uses a clone method. We could also call the method differently as it is 
not intended to be a full clone.



@Command(scope = "package", name = "exports", description = "Lists 
exported packages and the bundles that export them")
public class Exports extends OsgiCommandSupport {

     private PackageService packageService;

     public Exports(PackageService packageService) {
         this.packageService = packageService;

     protected Object clone() throws CloneNotSupportedException {
         return new Exports(packageService);

     protected Object doExecute() throws Exception {

Am 11.05.2012 07:45, schrieb Guillaume Nodet:
> Publishing the action as a service leads to the action having to be
> stateless and thread safe.  That's the opposite way compared to what we
> have now.  It may look nicer, but it does not mean it's easier to write for
> users.  Another consequence is that if the action of command arguments
> can't use properties.  So you kinda have to map a command to a method and
> arguments to parameters as done in gogo.  You may just want to investigate
> using gogo annotations and provide the missing features: a help system,
> completion, etc...
> http://svn.apache.org/repos/asf/felix/trunk/gogo/command/src/main/java/org/apache/felix/gogo/command/OBR.java
> On Fri, May 11, 2012 at 12:57 AM, Christian Schneider<
> chris@die-schneider.net>  wrote:
>> Absolutely the idea of publishing an action as a service should also make
>> defining command with SCR APIs much simpler. If you look at the SCR
>> commands in karaf they  are complex. If you just had to publish the Action
>> as a service they would look much nicer. Currently there is one action and
>> one command per scr command. This would simply turn into the action + scr
>> annotations for publishing.
>> Personally I dont like the scr syntax too much but users would have the
>> option to use it.
>> Christian
>> Am 10.05.2012 23:59, schrieb sully6768:
>>   Christian,
>>> I know there are lots of options out there but is there a reason why you
>>> wouldn't consider the SCR APIs that are now included with Karaf?  I
>>> implemented the module commands and management components using the SCR
>>> API
>>> in combination with the BND Annotation for reference.  The annotations,
>>> which are build-time only, are used to generate the SCR XML document so
>>> there isn't any need for getting into the gory details of the wiring.
>>> Just a thought.
>>> Best Regards,
>>> Scott ES
>>> http://fusesource.com
>>> --
>>> View this message in context: http://karaf.922171.n3.nabble.**
>>> com/Simpler-karaf-shell-**command-action-definition-**
>>> tp3974398p3978396.html<http://karaf.922171.n3.nabble.com/Simpler-karaf-shell-command-action-definition-tp3974398p3978396.html>
>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com

Christian Schneider

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

View raw message