I think you should definitely move this thread over to the karaf users list and continue the discussion there if you don't mind.
On Fri, Oct 15, 2010 at 18:26, Manuel Bernhardt <[email protected]>wrote: > Hi again! > > An update on this: after downloading Karaf 2.1, and spending a good > part of the day fighting (and understanding) how Spring DM deals with > custom namespaces, I was able to deploy a bundle with Spring-DM 2.0 on > Felix/Karaf (with DM 2.0 as a feature that I registered in a separate > provision xml file). > > Karaf 2.1 seems to come by default without Aries installed so I didn't > have any conflicts occurring there (or so I think at least). > > The issue I have now is that we use the Felix/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. > > My questions thus would be: > > - am I still on the right mailing-list or should I move this > discussion to the karaf users list? > > > - 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. > > (- it looks like http://karaf.apache.org/xmlns/shell/v1.0.0 isn't > online, whilst that would be handy to have) > > - 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) > > Thanks! > > Manuel > > > On Thu, Oct 14, 2010 at 9:42 PM, Manuel Bernhardt > <[email protected]> wrote: > > Hi! > > > > On Thu, Oct 14, 2010 at 3:22 PM, Achim Nierbeck <[email protected]> > wrote: > >> why don't you use the newer version of Karaf 2.1. > > > > On Thu, Oct 14, 2010 at 3:51 PM, Guillaume Nodet <[email protected]> > wrote: > >> Btw, karaf has become a top level project and has its own dedicated > mailing > >> lists (see http://karaf.apache.org/mailing-lists.html) ... > > > > Wow, it looks like I totally missed this. > > > > I got under the impression that Karaf 1.6 was the latest release, given: > > - http://felix.apache.org/site/apache-felix-karaf.html > > - http://felix.apache.org/site/downloads.cgi > > > > which appear much more frequently in searches (Google and friends). > > Perhaps it would be good to update these pages to point to the new > > Karaf site? (I guess I should send that to the Karaf users ML) > > > > On Thu, Oct 14, 2010 at 3:51 PM, Guillaume Nodet <[email protected]> > wrote: > >> The problem is that bundles with blueprint applications may be started > by > >> one or the other (or both) blueprint extenders. There may be some way > to > >> get around that, but I don't think anyone has really investigated the > >> problem (if any). > > > > So if I get it correctly, Aries is there by default in Karaf, and if I > > deploy a bundle with Blueprint services the platform may not know > > which implementation to use? Is there perhaps a way to specify bundle > > priority? (I'm not too acquainted to the OSGi spec) > > > > Mainly what I am after besides of the Blueprint spec implementation is > > DI support (annotation support and re-injection support) and the > > integration test support that Spring DM provides. Is there anything > > similar that could be used in the Karaf/Apache stack? > > > > Thanks! > > > > Manuel > > > > On Thu, Oct 14, 2010 at 3:51 PM, Guillaume Nodet <[email protected]> > wrote: > >> Having both Spring DM 2 and Aries Blueprint bundles deployed side by > side > >> hasn't been much tested. > >> The feature should not be too hard to write (yeah, that's the way to > go), > >> but the real problem may not be here. > >> The problem is that bundles with blueprint applications may be started > by > >> one or the other (or both) blueprint extenders. There may be some way > to > >> get around that, but I don't think anyone has really investigated the > >> problem (if any). > >> So before starting writing a feature, i would first try to see how they > >> cooperate together and fix the problems. I'd be glad to help doing so > if > >> you want. > >> > >> Btw, karaf has become a top level project and has its own dedicated > mailing > >> lists (see http://karaf.apache.org/mailing-lists.html) ... > >> > >> On Thu, Oct 14, 2010 at 11:38, Manuel Bernhardt > >> <[email protected]>wrote: > >> > >>> Hi all, > >>> > >>> I am struggling to get Spring DM 2 to run (as feature on Felix). If I > >>> understand things correctly, in order to use the Blueprint services in > >>> combination with Spring DM, I need this release (at least this is what > >>> the Spring site says). > >>> > >>> Karaf comes by default with Spring DM 1.2: > >>> > >>> ka...@root> features:list > >>> State Version Name Repository > >>> [installed ] [2.5.6.SEC01] spring karaf-1.6.0 > >>> [installed ] [1.2.0 ] spring-dm karaf-1.6.0 > >>> ... > >>> > >>> I started an attempt to make my own feature descriptor based on > >>> Karaf's one, but I am not entirely sure of which artifacts need to be > >>> part of the feature. I added my current attempt at the end of the > >>> mail. For the moment, it does not work, i.e. it fails when trying to > >>> deploy the feature. > >>> > >>> My question is: am I on the right track with attempting to create a > >>> custom feature descriptor? > >>> And, are there perhaps other means in order to get Spring DM 2.x > >>> support on the Felix/Karaf platform? > >>> > >>> Thanks! > >>> > >>> Manuel > >>> > >>> PS: I also posted a question on stack overflow: > >>> > >>> > http://stackoverflow.com/questions/3925405/how-to-get-spring-dynamic-modules-2-x-to-work-on-apache-felix-karaf > >>> > >>> > >>> > >>> <?xml version="1.0" encoding="UTF-8"?> > >>> <features name="spring-features"> > >>> <feature name="spring" version="3.0.2.RELEASE"> > >>> > >>> > > <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.aopalliance/1.0_3</bundle> > >>> > <bundle>mvn:org.springframework/spring-core/3.0.2.RELEASE</bundle> > >>> > <bundle>mvn:org.springframework/spring-beans/3.0.2.RELEASE</bundle> > >>> > <bundle>mvn:org.springframework/spring-aop/3.0.2.RELEASE</bundle> > >>> > >>> <bundle>mvn:org.springframework/spring-context/3.0.2.RELEASE</bundle> > >>> > >>> > <bundle>mvn:org.springframework/spring-context-support/3.0.2.RELEASE</bundle> > >>> </feature> > >>> <feature name="spring-dm" version="2.0.0.M1"> > >>> <feature version="3.0.2.RELEASE">spring</feature> > >>> > >>> > > <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.cglib/2.1_3_4</bundle> > >>> > >>> <bundle>mvn:org.springframework.osgi/spring-osgi-io/2.0.0.M1</bundle> > >>> > >>> > <bundle>mvn:org.springframework.osgi/spring-osgi-core/2.0.0.M1</bundle> > >>> > >>> > <bundle>mvn:org.springframework.osgi/spring-osgi-extender/2.0.0.M1</bundle> > >>> > >>> > > <bundle>mvn:org.springframework.osgi/spring-osgi-annotation/1.1.3.RELEASE</bundle> > >>> > >>> > > <bundle>mvn:org.apache.felix.karaf.deployer/org.apache.felix.karaf.deployer.spring/1.6.0</bundle> > >>> </feature> > >>> </features> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > >> > >> > >> -- > >> Cheers, > >> Guillaume Nodet > >> ------------------------ > >> Blog: http://gnodet.blogspot.com/ > >> ------------------------ > >> Open Source SOA > >> http://fusesource.com > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
