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.
