Note that @Autowired could be achieved by an explicit wiring in blueprint if the bean has setters.
Let me know if you need more help, that's an are i'm interested in going to the bottom, as I'm still unclear what works and what does not. On Fri, Oct 15, 2010 at 22:24, Manuel Bernhardt <[email protected]>wrote: > Salut! > > On Fri, Oct 15, 2010 at 7:19 PM, Guillaume Nodet <[email protected]> wrote: > > Yeah, that has changed in 2.1 where Karaf does not display the > pre-installed > > bundle anymore. > > Try 'la' in the console to see all the bundles. The Aries Blueprint impl > is > > used by a lot of bundles in karaf. > > Indeed. Well then I'll probably have some more surprises with the two > Blueprint implementations running side-by-side > > >> The issue I have now is that we use the Karaf shell extensions in > >> order to talk to our bundles via the console. This worked nicely with > >> a <command-bundle> declaration as long as I didn't inject dependencies > >> with spring (but wired them via hand). Now, spring not being the one > >> initializing the shell <action> classes, the dependencies are not > >> initialized. > > > > Not sure to exactly follow what you did with spring. > > Mainly the shell extension (extending OsgiCommandSupport) has a member > that is injected via @AutoWired. The type is declared in the spring > bundle context. > > >> - how does the shell console look for it's extension points? Will it > >> only look in <command-bundle> definitions in a OSGI-INF/blueprint > >> path, or would it in theory be fine if the definition were in a spring > >> bundle-context definition file (with a custom namespace mapping). My > >> aim would be to have spring initialize the instance (and wire its > >> dependencies) but still have the shell know about it / how to talk to > >> it. > > > > The console looks for services in the registry. The custom blueprint > > namespace is just a simple way to expose the service. > > To add a command to the console if you're no using blueprint, register a > > service implementing the org.apache.felix.service.command.Function > interface > > and with the osgi.command.function and osgi.command.scope service > > properties. Try "ls -a 14' for example in the karaf console to see a > bunch > > of those methods. The helper classes are located in the > > o.a.karaf.shell.console bundle. > > Great, thanks! > > >> - it looks like http://karaf.apache.org/xmlns/shell/v1.0.0 isn't > >> online, whilst that would be handy to have > > > > Wanna raise a JIRA, that should be fixed. > > You can find it at > > > http://svn.apache.org/repos/asf/karaf/tags/karaf-2.1.0/shell/console/src/main/resources/org/apache/karaf/shell/console/commands/karaf-shell.xsd > > in the mean time. > > Will file a ticket > > >> - does what I am trying to do make any sense at all? (I'm rather new > >> to the latest OSGi spec, and am not sure what the usual practices are) > > > > What are you trying to do? Do you only need to register a set of commands > > using spring-dm ? Do you really need to use the blueprint implemnttion > from > > spring? > > Actually I don't care so much for the blueprint implementation. What I > am after is spring's dependency injection toolset and the integration > test facility ( > http://static.springsource.org/osgi/docs/2.0.0.M1/reference/html/testing.html#testing:integration > ). > If I understood things right, I do need spring dm to be running on the > platform in order to get those, or not? > > Thanks, > > Manuel > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
