So I really have 2 concerns with your approach: * we expose in the OSGi registry some services which are not supposed to use * we use introspection on exported services It seems to me that we are kinda breaking multiple aspects of the OSGi registry contract.
I'll continue the discussion on the original thread. 2014-02-15 16:10 GMT+01:00 Christian Schneider <[email protected]>: > Hi all, > > I have created an experimental whiteboard extender for Action objects to > export them as commands. > > See: > https://issues.apache.org/jira/browse/KARAF-2762 > > And this as an example: > https://github.com/cschneider/Karaf-Tutorial/tree/master/db/command2 > > The idea is that you simply create the Action in code like today and > export it as a service with the di framework of your choice. The action is > then picked up by the whiteboard extender and exposed as a command. > > One problem with this approach was that we need to create a new Action > instance for each call to the command. I have found a simple way to do > this. Basically I simply do class.newInstance() and copy all field values > from the template. I also found a way to define completers. I simply check > the Action for fields of type Completer and add these to the list of > completers. > > I think this approach has some advantages compared to the DSL model > Guillaume proposed. > > 1. We have very loose coupling as the use only needs to use interfaces and > annotations > 2. The solution is framework agnostic. You can use this model with > blueprint, ds, plain OSGi API, ... > 3. You can leverage the dependency injections of your framework. Even the > completers can be injected which is nice if they need services to work. > > What do you think? > > Christian > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
