Unless I am missing something, regarding SCR/OSGi users, I really don't see a need for anything new other than maybe documenting what I did. My biggest issue in writing the SCR Command and Management Components was the discovery of how to uncover what blueprint was abstracting for command publication. All the examples and documentation are from a blueprint perspective (at least when I did them). Once figured out, it wasn't that difficult and a pattern emerged.
My experience is that the SCR developer wants more control and doesn't trust the "magic" of the larger dependency injection frameworks. My last 3 customers have all had concerns and would not allow them. (There opinions do not necessarily reflect my own.) :) Taking that down another level, SCR just abstracts the basic OSGi APIs and sprinkles in some dynamic discovery and activation. Therefore if you can use SCR, you can use plain OSGi to do the same thing. Seems to me just showing how and what the patterns are would be sufficient. Scott England-Sullivan FuseSource, Integration everywhere http://fusesource.com Guillaume Nodet wrote > > Users are free to use whatever they want to expose command. The only real > requirement is to > expose a gogo Function object in the registry and that's where the service > layer is. > > The blueprint command helps for blueprint. People can also use > the SimpleCommand if they don't use blueprint which would make things > easier for them I think. The following line is all that is needed to > export a command: > > SimpleCommand.export(bundleContext, MyAction.class); > > But then, you obviously can't use injection ... > > I guess we can also provide a different way for SCR users if needed. > > On Fri, May 11, 2012 at 10:15 AM, Christian Schneider < > chris@> wrote: > >> I think for blueprint users our current aproach is fine. The blueprint >> prototypes automate the cloning of the action. So I think for blueprint >> we can keep things as they are. Perhaps just with a simpler schema but >> that is only a small gain. >> >> The service aproach would help users of SCR, plain OSGi or other >> frameworks where we have no special support. It also would help to make >> our >> implementations private. >> Currently we expose AbstractCommand which knows about the >> DefaultActionPreaparator which knows about the converter impls. So >> basically most of our impls are public. >> With the service aproach and addtionally the blueprint schema we could >> make all these impls private. So we have more freedom to change things >> and >> people have a small and simple API to use. I thought about other ways to >> achieve that but found no good alternative. >> >> Christian >> >> >> Am 11.05.2012 09:18, schrieb Jean-Baptiste Onofré: >> >> 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@> 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/****<http://svn.apache.org/repos/**asf/felix/trunk/gogo/command/**> >>>>>> src/main/java/org/apache/****felix/gogo/command/OBR.java<ht** > >>>>> tp://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@> 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/****<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 >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> Talend Application Integration Division http://www.talend.com >> >> > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > FuseSource, Integration everywhere > http://fusesource.com > -- View this message in context: http://karaf.922171.n3.nabble.com/Simpler-karaf-shell-command-action-definition-tp3974398p3980078.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
