Whiteboard extender for commands / actions

[Christian Schneider <ch...@die-schneider.net>]

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

Re: Whiteboard extender for commands / actions

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Christian,

good idea.

Just a note (in term of wording), it means that a command has to 
implement Action, which is not necessary the case.
For instance, ActiveMQ command directly extend gogo AbstractCommand, 
which implements gogo Function. So using the whiteboard extender, in the 
Action generator (in ActiveMQ command wrapper, I used the same logic for 
Hadoop commands) has to expose Action as a service (which is actually 
the case using BlueprintContainerAware and the fact that the actual 
commands are describe in the BlueprintContainer).

Though, I wonder if we may not have some "side effects" with this 
approach, especially in term of thread isolation and classloading (just 
thinking, I have to take a deeper look).

I will take a deeper look without jet lag tomorrow ;)

Regards
JB

On 02/15/2014 04:10 PM, Christian Schneider wrote:
> 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
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Whiteboard extender for commands / actions

[Guillaume Nodet <gn...@apache.org>]

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 <ch...@die-schneider.net>:

> 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
>
>