karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [DISCUSS] Java DSL for writing commands
Date Tue, 18 Feb 2014 13:24:23 GMT
By the way, even without using github, you can use your own branch for 
PoC/prototyping/proposal.

For instance, I do:

git branch my-branch
git checkout my-branch

I work on this branch for new features or bug fixes.
Periodically, I merge from master:

git merge master

When they are no real discussion, I merge back to master and push:

git checkout master
git merge my-branch
git push

But you can also push your branch on wip for discussion (and when it's 
done and the branch merged, we can remove the branch).

github is fine two (it's just two different upstream).

Regards
JB

On 02/18/2014 09:30 AM, Christian Schneider wrote:
> 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
> this:
>
> @Bean(id="selectCommand")
> @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;
>
>      @Inject(ref="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.
> See
> https://github.com/cschneider/Karaf-Tutorial/blob/master/tasklist-cdi/tasklist-webservice/src/main/java/net/lr/tasklist/webservice/TaskService1.java
>
> 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
>
> Christian
>
>
> 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.
>>
>>
>

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

Mime
View raw message