Have you looked at the blueprint annotations provided by aries ? I'm personally not a big fan of those but they could be used if needed.
On Wed, May 9, 2012 at 5:45 PM, Christian Schneider <[email protected] > wrote: > I know this is an issue. One idea is to use blueprint bean ids in the > property of the @Command annotation. > So we could look up the completers this way. > > We could also list completer classes in the annotation and inject suitable > beans by type. > > You are right though that this is rather a job for an annotation based > injection framework which I am not planning to recreate. > I hope though that we soon have something suitable we can simply use. > > Christian > > Am 09.05.2012 17:19, schrieb Guillaume Nodet: > >> 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<chris@die-schneider.* >> *net <[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<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 >>> >>> >>> >> > > -- > > 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
