Hi, yes this setup looks good to me, just one "note", don't know if you're already doing it, for the camel part make sure it is all blueprint / JavaDSL for the Camel route :)
Ok, now since I have this picture, the big headaches are regarding the "apples" and "oranges" bundles, cause those need spring. Now after also reading the response of Tim, that the spring-dm version range is [2.5.6,4) I'd say here we have our big issue (and I didn't know of the version restriction ... but makes sense) Now how to tackle this? First of all let's check some possibilities: 1) is it possible to run with spring 3.x, if yes forget about the rest, just do it ;) 2) Remove the spring dependencies and replace with Blueprint .... cumbersome, and one might loose working code ... not really an option 3) Switch to Gemini Blueprint, this seems to work better with Spring as it's supposed to replace Spring-DM 1.x ... this will need to switch to region support which is available with Karaf 3.x ... but to be honest I don't know how good it works right now 4) Re-Package the spring-dm bundles or alter the Manifest for the version Range. This can either be achieved with 1) using the maven-shade-plugin and an adapted Manifest file that "widens" the import range to [2.5.6, 4.1) or [2.5.6, 5). Another possibility, alter the Manifest of the spring-dm bundles by adding a Fragment bundle to it that does "widen" the import range. Only downside of this approach, we don't know how good spring-dm really works with Spring 4 Right now I only tested (and this has only been marginally) with Spring 3 and Spring-DM. regards, Achim -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Software Architect / Project Manager / Scrum Master 2014-05-16 19:52 GMT+02:00 constv <[email protected]>: > Achim, thanks so much for taking the time to look into this and help me > out. > > My original architectural approach (that has worked for me before) has been > the following. I have a set of well-defined bundles, where one bundle > consolidates some common (reusable, to be shared with other bundles) > functionality, utilities, data access related definitions, etc., Each of > the > other bundles represents a "vertical" - self-contained component for a > particular functinal domain. All such functional bundles have a dependency > on the common bundle, and some may have uni-directional dependencies on > other functional bundles. Some of such bundles implement Camel routes. > Something like this: > > Common Bundle: > - data source def (JNDI-exported via OSGi) > - common service1 instance (exported via OSGi) > - common service2 instance (exported via OSGi) > etc. > - Common base/abstract classes (not specific to functional domains) > - General-purpose exception classes (not specific to functional domains) > - General-purpose utilities > - Common application configuration > etc. > Blueprint-wired, exports common service bean references via OSGi registry > > "Apples" Bundle: > - apples-specific configuration > - apples-specific classes (services, DAO implementations, utils, > exceptions, etc.) > - apples-specific Camel route(s) (route builders, processors, etc.) > etc. > Spring-wired; depends on the Common bundle; imports shared common > references from Osgi Svc Registry (using spring-dm) > > "Oranges" bundle: > - oranges-specific configuration > > - apples-specific classes (services, DAO implementations, utils, > exceptions, etc.) > - apples-specific Camel route(s) (route builders, processors, etc.) > etc. > Spring-wired; depends on the Common bundle; imports shared common > references from Osgi Svc Registry (using spring-dm) > ... > > and so on... > > > The "apples", "oranges", etc. components used to be standard non-OSGi > components/JARs used in single-app-context applications. They are quite > clean and elegant, and are all wired mostly with Spring annotations. > > So, now I am looking for a way to configure my OSGi application feature > (and > Karaf 3.0.x) so that I could deploy the application without Karaf > exceptions... D'uh! :-) > > Here's what the feature repositories and boot entries in my > /org.apache.karaf.features.cfg/ file look like right now: > > > *featuresRepositories*=mvn:org.apache.karaf.features/standard/3.0.1/xml/features,mvn:org.apache.karaf.features/enterprise/3.0.1/xml/features,mvn:org.ops4j.pax.web/pax-web-features/3.1.0/xml/features,mvn:org.apache.karaf.features/spring/3.0.1/xml/features,mvn:org.apache.camel.karaf/apache-camel/LATEST/xml/features > > > *featuresBoot*=config,standard,region,package,kar,ssh,management,jndi,jdbc,spring,spring-jdbc > > > The reason I have added some core features to the list of the features to > boot is because eventually I would need to pre-configure Karaf with all the > necessary core features my application needs, and then allow deploying the > application as a KAR file with only the 3rd-party dependencies and my > bundles in it. > > Does this make sense? Anything I should be doing differently? > > Again, thank you very much for your help! > > > > > Achim Nierbeck wrote > > Hi, > > > > I'm gonna try to give you a quick response and will get back to this mail > > later with a bit more time. > > First of all I'm not suggesting to drop spring, you've been referring to > > camel at one point that's where I've got the impression that you might > > only > > need blueprint. > > But it might help already if you could give us an overview of the > > architecture, or the way you've cut the bundles and the purposes. > > > > For example if you have camel routes that reference your spring beans as > > OSGi services you should consider to split this apart. Use camel with > > blueprint and register your services via spring DM. > > > > Regards, Achim > > > > > > -- > View this message in context: > http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033152.html > Sent from the Karaf - User mailing list archive at Nabble.com. >
