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 Mon, 17 Feb 2014 16:22:29 GMT
Hi Guillaume,

you asked about my goals. I think these are my main goals:

1. The user should be able to expose commands without the boilerplate 
code. So basically we agree that ideally the user should just define the 
Action + annotations in his code
2. The user should only be exposed to the API (again actions + annotations)
3. The solution should ideally be framework agnostic. For example a 
blueprint namespace based solution will not work with gemini blueprint
4. The user should be able to do as much of his injections with his 
standard framework as possible

So I assume we just differ in goal 3 and you additionally have the goal 
of using services only for calling code over a published interface.

So basically if we just look at the user java code our solutions look 
very similar. The user defines an action with annotations.

In my whiteboard approach the user only exposes the Action as a service. 
The whole work of interpreting the meta data is done in the command 
exporter. Unfortunately this is on the other side of an OSGi service. So 
we kind of abuse the service to publish a template object. See below why 
I agree this is not good but also not that problematic.

In your proposal the work is done in a framework specific extension. I 
like your new proposal much more than the first one already as we reuse 
the DI of the framework.
So your proposal mainly differs from my goals in the 3rd goal. The 
disadvantage I see in your solution is that we have to create an 
extension for each framework.
If we assume that we only support aries blueprint and DS then this is 
surely doable. Still it would be a lot more effort short term as well as 
long term.

See some more comments inline....

On 17.02.2014 16:30, Guillaume Nodet wrote:
> 2014-02-17 16:01 GMT+01:00 Christian Schneider <chris@die-schneider.net>:
>> I can very well imagine that this would work. I am not sure if it is a
>> good idea thought.
>> We would recreate parts of the dependency injection framework.
> Well, which parts ? I don't understand.  My first attempt was indeed
> creating a very small DI framework, but here, my goal is to delegate
> everything to the real DI.  The namespace handler would simply be enhanced
> to discover the actions and the injection points and create blueprint
> metadata out of it.  This would obviously require a bit of reflection on
> the classes, but nothing different from your proposal.
>> In any case it would require that we implement a solution for each DI
>> framework out there. Additionally we would have to keep our extensions up
>> to date with the framework evolution.
>> While I can understand that my approach has its own fallacies I think it
>> would create less issues and less work even in the long term.
>> What I could imagine as a kind of middle ground is to simply have a
>> special processing for the @Command annotation.
>> For example in blueprint we could have:
>> <bean class="MyAction">
>> .... do some injections ---
>> </bean>
>> We then let blueprint do its injections but also create the
>> BlueprintCommand for it and export the service. So this would be very
>> similar to the namespace but not requiring it. Not sure if this is possible
>> in blueprint though. The nice thing with this approach is that it might
>> also work with blueprint annotations. In any case I propose we let the
>> framework do its injections and only work with the fully injected Action.
> Ok, so I misunderstood as it seems we don't have the same goals.  My point
> is to make typical things easy for the user and not having to write this
> boilerplate code. I.e. in 95% of the use cases, the user should not have to
> deal with blueprint xml or DS specific annotations.
> If the user wants to fully reuse its DI, he can do so, but our current
> model is quite verbose.  We have such an example for blueprint:
> https://github.com/apache/karaf/blob/master/shell/console/src/main/resources/OSGI-INF/blueprint/karaf-console.xml#L56
> and for DS:
> https://github.com/apache/karaf/blob/karaf-3.0.0/scr/command/src/main/java/org/apache/karaf/scr/command/DetailsCommandComponent.java
> So I'm not trying to change the above model, rather keep this model (Action
> / Command), but make things easier for the user to register commands.   I
> first got rid of the completers and used annotations to wire them through
> OSGi services, now I want to get rid of exposing the command in the OSGi
> registry manually, even if we delegate to the underlying DI framework.
> IIUC, what you're proposing is a new simplified model so that users don't
> have to deal with commands but only with actions.  While I don't have any
> problems with discussing a new model, I'd like to avoid misusing our
> current model (and breaking a few OSGi contracts).  More importantly, your
> proposal does not help a single bit solving my problem.
In my model there is still command and action. The only difference is 
that the Action is exposed as a service while in your model the Action 
is only
exposed to the framework extension. The other steps are quite the same I 
> Though, if my goal can be achieved somehow, there's no real value left in
> your proposal, as it would only help in 1% of the cases that can't be
> covered by my proposal, and I think those will be the same that can't be
> covered by the blueprint xml handler now (i.e. exit and help commands).
I see it quite the other way round. My solution is much simpler and 
covers 100% of the problem space. The downside is an unusual usage of 
OSGi services.
I think my approach does not really violate any contracts the OSGi spec 
poses on services. The fact that we typically use services only with 
their interface is
not mandated by the spec as far as I can tell. Still I see that using a 
service to expose a template object is quite unusual. So I would really 
be interested in a solution that avoids this while also
being framework agnostic.

As both solutions do work I think it is a question of weighing the pros 
and cons. I am still searching for a better way though. So lets continue 
experimenting for some more time. Perhaps we really find something better.


Christian Schneider

Open Source Architect

View raw message