How do you plan to inject services into completers ? Unless you define a
full blown annotation injection mechanism for OSGi and get rid of
blueprint, I don't really understand how that will work.
For example in admin-core, the completers are defined as following:
<reference id="adminService"
interface="org.apache.karaf.admin.AdminService" />
<reference id="featuresService"
interface="org.apache.karaf.features.FeaturesService" />
<bean id="instanceCompleter"
class="org.apache.karaf.admin.command.completers.InstanceCompleter">
<property name="adminService" ref="adminService" />
</bean>
<bean id="allFeatureCompleter"
class="org.apache.karaf.features.command.completers.AllFeatureCompleter">
<property name="featuresService" ref="featuresService" />
</bean>
<bean id="featureUrlCompleter"
class="org.apache.karaf.features.command.completers.FeatureRepositoryCompleter">
<property name="featuresService" ref="featuresService" />
</bean>
I don't get how you plan to do that with an annotation.
On Wed, May 9, 2012 at 5:08 PM, Christian Schneider <[email protected]
> wrote:
> We currently either use the blueprint namespace or the AbstractCommand and
> a service definition to define commands. This has some shortcomings:
> - The blueprint namespace definition is a bit verbose and at first I did
> not understand that actions in the xml can be injected like beans
> Example:
>
> <command-bundle
> xmlns="http://karaf.apache.**org/xmlns/shell/v1.1.0<http://karaf.apache.org/xmlns/shell/v1.1.0>
> ">
> <command>
> <action class="org.apache.karaf.shell.**
> commands.impl.WatchAction">
> <property name="commandProcessor" ref="commandProcessor"/>
> </action>
> <completers>
> <ref component-id="**commandCompleter" />
> <null/>
> </completers>
> </command>
> </command-bundle>
>
> - The other way using AbstractCommand and a service def is even more
> verbose and exposes a lot of implementation details like the
> DefaultActionPreparator
>
> <bean id="commandCompleter" class="org.apache.karaf.shell.**
> console.completer.**CommandsCompleter"/>
> <service>
> <interfaces>
> <value>org.apache.felix.**service.command.Function</**value>
> <value>org.apache.karaf.shell.**console.CompletableFunction</**
> value>
> </interfaces>
> <service-properties>
> <entry key="osgi.command.scope" value="*"/>
> <entry key="osgi.command.function" value="help"/>
> </service-properties>
> <bean class="org.apache.karaf.shell.**console.commands.**
> BlueprintCommand">
> <property name="blueprintContainer" ref="blueprintContainer"/>
> <property name="blueprintConverter" ref="blueprintConverter"/>
> <property name="actionId" value="help"/>
> <property name="completers">
> <list>
> <bean class="org.apache.karaf.shell.**
> console.completer.**CommandNamesCompleter"/>
> </list>
> </property>
> </bean>
> </service>
>
> <bean id="help" class="org.apache.karaf.shell.**help.impl.HelpAction"
> activation="lazy" scope="prototype">
> <property name="provider" ref="helpSystem"/>
> </bean>
>
>
> So here is what I propose:
>
> The first thing is to add a complerers property to the @Commands
> annotation. This is the last bit we need to make sure the annotations
> provide all metadata of an action.
> Then the idea is to simply define the action as a blueprint bean and
> publish it as an OSGi service. We then have an extender that adapts these
> to the felix gogo commands.
>
> So the blueprint code for the help example above would look like:
> <service interface="org.apache.karaf.**shell.commands.Action">
> <bean id="help" class="org.apache.karaf.shell.**help.impl.HelpAction"
> activation="lazy" scope="prototype">
> <property name="provider" ref="helpSystem"/>
> </bean>
> </service>
>
> With the upcoming blueprint annotations we could simply annotate the
> Action class and need no blueprint code at all. The above style would also
> work much better with declarative services. If you look at the scr module
> in karaf you see how complicated it is till now to create a command in ds.
>
> One problem with the aproach is of course that the Action has to be
> created per execution. So we need to find a good way to clone the Action
> object. To a degree this problem is already present int the current
> solution.
>
> So what are the advantages:
> - The user code only depends on some very few interfaces like Action and
> the annotations. AbstractCommand and similar are not needed anymore and the
> impls can be private
> - The blueprint syntax is quite concise and does not need a special
> namespace
> - Using BP annotations the syntax is even more concise as no xml is
> needed. This would not be possible with the current way
>
> So what do you think?
>
> Christian
>
> --
> 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
