I've also added annotation support for SCR, with the injection completely controlled by SCR In terms of SCR, the only thing is to run the BND plugin located in scr/support jar. This plugin will scan our annotations and produce the correct SCR definitions to register commands.
https://git-wip-us.apache.org/repos/asf?p=karaf.git;a=commitdiff;h=291d564eba4102a33ba79ff60a0777340ea07013 For this to work, a command class is injected into the generated bundle and is registered as a service with the needed SCR references. Those references are used when instantiating the actions and injected as needed. This means that now, most commands can be written exactly the same way with blueprint, SCR or even no underlying DI. We still follow our model of Action / Command, so it's fully compatible, but much less verbose and completely decoupled from the injection framework used. I'm done with this work right now but opened to any comments on how to improve this. 2014-02-17 18:29 GMT+01:00 Guillaume Nodet <[email protected]>: > 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. > > > > > 2014-02-17 17:46 GMT+01:00 Christian Schneider <[email protected]>: > > Hi Guillaume >> >> I just tested my whiteboard approach with blueprint. >> It seems that indeed blueprint adds a proxy even for the exported >> service. So it is not possible to read the meta data of the Action object >> in this case. >> So unless there is a way to avoid the proxy creation this really speaks >> against my solution as it would not work with blueprint. >> >> >> Christian >> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> http://www.talend.com >> >> >
