karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Simpler karaf shell command/action definition
Date Thu, 10 May 2012 06:29:47 GMT
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
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message