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: [DISCUSS] Java DSL for writing commands
Date Tue, 18 Feb 2014 08:30:20 GMT
Hi Guillaume,

I just looked into your code on github. Btw. I think your choice to use 
the github fork and branches to showcase designs is really great. I will 
also use this in the future to have a nicely separated environment as a 
base for discussion.

In your code you created two new DI annotations @Service and @Reference. 
I think we should not go this way. Instead we should leverage the DI 
options the framework already provides.
So for blueprint this would be the xml configuration and the blueprint 
annotations. The xml configuration would result in what we already have 
with the namespace support which is not great but also not too bad. The 
blueprint annotations should result in a very similar result like the 
one you showcased here. I know blueprint annotations are not really 
great but they are what the framework provides and chances are good that 
they improve over time.

So for the blueprint annotations I would imagine an action to like like 

@Command(scope = "db", name = "select", description = "Selects a datasource")
public class SelectCommand implements Action {
     @Argument(index=0, name="name", required=false, description="DataSource JNDI name", multiValued=false)
     String name;

     private DbSelect dbSelect;

     public void setDbSelect(DbSelect dbSelect) {
         this.dbSelect = dbSelect;

So basically I propose that we simply use the existing annotations. Now 
the question is: Could we add handling for our command annotation into this?

What I would like to have is that we provide some karaf specific 
extension that simply gets called for any @Command annotated bean and 
that takes the fully injected Action bean and pulishes it using the 
blueprint command. Ideally this might even work without a special 
namespace handler as we are using regular beans. Unfortunately I do not 
know how to implement this. If you can give me some hints how to do it I 
am willing to code this of course.

The advantages would be:
- We do not need additional annotations
- We do not need to scan the classpath for annotated classes (ideally 
the framework will do this for us)
- We reuse the injection framework and profit from any enhancements that 
are done in it
- The user will feel at home as he can use all the features of DI he 
already knows.

The special @Reference annotation you proposed has the problem that 
users may soon say. It is nice but I want injection by name or injection 
by whatever extra feature blueprint might have then. Or they want to 
inject config admin properties into the command. So over time we would 
recreate portions of a DI framework.

I think a similar method like this might also work for CDI. For CDI I 
already implemented a qualifier based auto export for CXF endpoints 
which is basically the same problem. The user provides a bean and wants 
to use any injections on it. The bean then has to be taken by CXF and 
postprocessed in a CXF specific way to export it as an endpoint. Which 
is very similar to what we do for Actions.
There I had to use an additional annotation as I was only able to react 
on @Qualifier annotations. Ideally we would also be able to simply react 
on @WebService. Unfortunately I did not find out how to do it.

Best regards


On 17.02.2014 18:29, Guillaume Nodet wrote:
> Fwiw, I've implemented the annotation support for blueprint.
> See https://github.com/gnodet/karaf/commits/inject
> An example for the jms command is at
> https://github.com/gnodet/karaf/commit/9f2854da465fb55e57ec01952629e732273786a8
> So you're right, that if we want that level of integration for each DI
> technology, we'd have to write a layer for each one.  However:
>    * I haven't seen many different DI framework used to define commands
>    * we still have the solution I proposed in my first draf which is DI
> agnostic
>    * in the rare cases where none of the above would fit, the user can still
> use the full model (as it was the case previously with SCR), or the java
> DSL, which even if it couples a bit the service exposition to karaf, still
> removes lots of the boiler plates for common use cases
> Given your experiments do not seem to lead to usable results, and unless
> someone objects, I'll go ahead and commit what I have.

Christian Schneider

Open Source Architect

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