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
On Fri, May 11, 2012 at 12:57 AM, Christian Schneider<
[email protected]> 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
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
