karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Simpler karaf shell command/action definition
Date Thu, 10 May 2012 07:52:33 GMT
I used the blueprint annotations that should be available in the next 
aries release.
 From the snytax I would prefer CDI annotations but I do not think the 
frameworks for CDI are ready for OSGi at the moment.

On the other hand I do not really want to get rid of blueprint at this 
point. For example I think
it makes a lot of sense to define references to external services in the 
blueprint context and
use @Inject in the commands to reference them.

I think at the moment there is a lot of movement around annotations in 
OSGi so probably we simply
wait a bit before switching larger chunks of the Karaf code. Still we 
could provide the layer that takes
the services and creates the commands out of them. So people could start 
experimenting with it.


Am 10.05.2012 08:29, schrieb Guillaume Nodet:
> I would not try to add real injection annotations unless we either have
> them supported by blueprint or switch to a different framework, so the
> @Service @Completer and @Inject are not a good idea now.
> If we want to get rid of blueprint, I'd consider standardizing around the
> CDI annotations, but we need to find a framework that plays nicely with
> OSGi first (or implement it in aries blueprint).
> On Thu, May 10, 2012 at 8:12 AM, Christian Schneider<
> chris@die-schneider.net>  wrote:
>> I must have missed that. In this case we do not need to hurry with a new
>> schema. I will
>> prepare a schema and some demo code as soon as 3.0 is out.
>> At the moment I think the best starting point is this for the xml:
>>         <shell:action class="org.apache.karaf.admin.**command.**
>> ChangeRmiServerPortCommand">
>>             <property name="adminService" ref="adminService" />
>>             <shell:completer ref="instanceCompleter" />
>>         </shell:action>
>> For the annotation based config we could do something like:
>> |@Command(scope = "test", name = "hello", description="Says hello")
>> @Completer{beanId="**myCompleter"}
>> @Service
>> public class HelloShellCommand implements Action {
>> @Inject(ref="|**blueprintBundleContext|")
>> BundleContext context;
>>     @Override
>>     protected Object doExecute() throws Exception {
>>         System.out.println("Executing Hello command");
>>         return null;
>>     }
>> }|
>> Btw. the annotation based config would allow to have a parent class with a
>> common service that gets injected. So not every command has to do it. I
>> think it might
>> make a lot off sense to use annotation based config in karaf itself as it
>> requires much less code. It also reacts nicer when doing refactorings as it
>> cant happen that you still
>> refer to the old class name.
>> Christian
>> Am 09.05.2012 19:50, schrieb Guillaume Nodet:
>>   The 1.1.0 version has already been released from the 2.x branch, so it has
>>> to be a 1.2 if we keep the old elements in the same schema, or a 2.0 if we
>>> remove the old elements from the schema (even if the handler
>>> implementation
>>> supports both namespaces).
>>> On Wed, May 9, 2012 at 6:59 PM, Christian Schneider<chris@die-schneider.*
>>> *net<chris@die-schneider.net>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com


Christian Schneider

Open Source Architect
Talend Application Integration Division http://www.talend.com

View raw message