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.
Christian
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<
[email protected]> 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<[email protected]>
--
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
