karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Simpler karaf shell command/action definition
Date Fri, 11 May 2012 07:18:58 GMT
Agree,

What's the exact value comparing to what we have currently ?
I would prefer to a full "technical" definition of the commands and 
avoid logic behind.

Regards
JB

On 05/11/2012 09:15 AM, Guillaume Nodet wrote:
> I know we could find hacks to workaround that problem, what I don't really
> understand is the benefit.  The user now would have to care about that
> instead of relying on the framework to do it and leveraging blueprint
> prototypes.  Also it mixes the business logic with the completers /
> parameters parsing.
>
> I've agreed to simplify things on the schema, but that seems to go in the
> opposite direction to me (for no real benefit for the end user).
>
> On Fri, May 11, 2012 at 9:03 AM, Christian Schneider<
> chris@die-schneider.net>  wrote:
>
>> 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.
>>
>> Christian
>>
>> ---
>>
>> @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) {
>>         super();
>>         this.packageService = packageService;
>>     }
>>
>>     @Override
>>     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<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<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
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message