You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by constv <cv...@healthedge.com> on 2014/05/12 17:48:25 UTC
Spring 4.0.2 and spring-dm
Hi,
I am using Karaf 3.0.2 and trying to deploy a KAR-archived application that
uses Spring 4.0.2. My bundles contain Spring configuration files with the
following property placeholder resolver configurations:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ctx="http://www.springframework.org/schema/context"
xmlns:osgi-springdm="http://www.springframework.org/schema/osgi"
xmlns:jee="http://www.springframework.org/schema/jee"
xmlns:osgix="http://www.springframework.org/schema/osgi-compendium"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
http://www.springframework.org/schema/osgi
http://www.springframework.org/schema/osgi/spring-osgi.xsd
http://www.springframework.org/schema/jee
http://www.springframework.org/schema/jee/spring-jee.xsd
http://www.springframework.org/schema/osgi-compendium
http://www.springframework.org/schema/osgi-compendium/spring-osgi-compendium.xsd">
<bean
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="propertiesArray">
<array>
<osgix:cm-properties id="healthedge.prototype"
persistent-id="prototype"/>
<osgix:cm-properties id="my.props.one"
persistent-id="props.one"/>
<osgix:cm-properties id="my.props.two"
persistent-id="props.two"/>
</array>
</property>
</bean>
...
</beans>
In Karaf, I ensure that the Spring (v 4.0.2.RELEASE_1) and spring-dm (v.
1.2.1) features are installed/activated. I even tried explicitly
uninstalling Spring 3.2.4.RELEASE. However, I am always getting the
following exceptions when deploying the KAR file:
Offending resource: URL
[bundle://126.0:0/META-INF/spring/my-bundleX-context.xml]
Bean ''; nested exception is
org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: Unable to locate Spring NamespaceHandler for XML
schema namespa
mework.org/schema/osgi-compendium]
Offending resource: URL
[bundle://126.0:0/META-INF/spring/prototype-filepoller-context.xml]
Bean ''
-> Property 'propertiesArray'
at
org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:68)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.error(BeanDefinitionParserDelegate.java:325)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseBeanDefinitionElement(BeanDefinitionParserDelegate.java:581)[112:org.springframework.beans:*3.2.4.RELEASE*]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseBeanDefinitionElement(BeanDefinitionParserDelegate.java:479)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseBeanDefinitionElement(BeanDefinitionParserDelegate.java:448)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.processBeanDefinition(DefaultBeanDefinitionDocumentReader.java:312)[112:org.springframework.beans:3.2.4.
at
org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseDefaultElement(DefaultBeanDefinitionDocumentReader.java:203)[112:org.springframework.beans:3.2.4.RE
at
org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:182)[112:org.springframework.beans:3.2.4.R
at
org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.doRegisterBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:139)[112:org.springframework.beans:3.
at
org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:108)[112:org.springframework.beans:3.2.
at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:174)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:209)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:180)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:164)[118:org.springframework.osgi.core:1.2.1]
at
org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:136)[118:org.springframework.osgi.core:1.2.1]
at
org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130)[114:org.springframework.context:3.2.4
at
org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:537)[114:org.springframework.context:3.2.4.RELEASE]
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$800(AbstractDelegatedExecutionApplicationContext.java:69)[118:org.springframework.osg
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$3.run(AbstractDelegatedExecutionApplicationContext.java:269)[118:org.springframework.osgi.co
at
org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)[118:org.springframework.osgi.core:1.2.1]
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.startRefresh(AbstractDelegatedExecutionApplicationContext.java:247)[118:org.springframework.
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:214)[119:org.s
nder:1.2.1]
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:169)[119:org.sp
der:1.2.1]
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175)[118:org.springframework.osgi.
at
org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:716)[119:org.springframework.osgi.extender:1.2.1]
at java.lang.Thread.run(Thread.java:745)[:1.7.0_55]
Caused by:
org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: Unable to locate Spring NamespaceHandler for XML
schema namespace [http://www.spr
osgi-compendium]
Offending resource: URL
[bundle://126.0:0/META-INF/spring/prototype-filepoller-context.xml]
Bean ''
-> Property 'propertiesArray'
at
org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:68)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:80)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.error(BeanDefinitionParserDelegate.java:318)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1435)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseNestedCustomElement(BeanDefinitionParserDelegate.java:1491)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parsePropertySubElement(BeanDefinitionParserDelegate.java:1045)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCollectionElements(BeanDefinitionParserDelegate.java:1229)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseArrayElement(BeanDefinitionParserDelegate.java:1191)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parsePropertySubElement(BeanDefinitionParserDelegate.java:1093)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parsePropertySubElement(BeanDefinitionParserDelegate.java:1033)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parsePropertyValue(BeanDefinitionParserDelegate.java:1023)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parsePropertyElement(BeanDefinitionParserDelegate.java:921)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parsePropertyElements(BeanDefinitionParserDelegate.java:782)[112:org.springframework.beans:3.2.4.RELEASE]
at
org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseBeanDefinitionElement(BeanDefinitionParserDelegate.java:566)[112:org.springframework.beans:3.2.4.RELEASE]
Note that the offending library is from the wrong version of Spring. What's
going on? I define all my spring and spring-osgi dependencies as "provided"
in my POM files. I activate the correct version of Spring. What causes the
problem?
Thanks for any help!
--
View this message in context: http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Spring 4.0.2 and spring-dm
Posted by Tim Jones <ti...@mccarthy.co.nz>.
I am not sure if I am helping here but the spring-dm feature depends on
spring [2.5.6,4) as seen below
root > features:info spring-dm
Description of spring-dm 1.2.1 feature
----------------------------------------------------------------
Feature has no configuration
Feature has no configuration files
Feature depends on:
spring [2.5.6,4)
so I think uninstalling Spring 3.2.4.RELEASE is going to cause you problems.
This is also a concern to us as we have significant investment in Spring +
(camel +other) and we don't have a clear migration path post Spring 3.
I can also testify to a fair amount of frustration in getting a particular
version of Spring to run. Our approach was to redefine (override) the
default Spring features and their versions in a custom features file.
--
View this message in context: http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033171.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Spring 4.0.2 and spring-dm
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,
no, this wouldn't require a compile time dependency.
You just need an "extra" module in your project setup.
a/ a module containing the "re-packaged" Spring-DM including as feature
b/ a module containing either one or more fragment bundles to alter the
Version-Range.
With a) you'd need to add an extra feature to your features.xml containing
a custom spring-dm
With b) you need one or more fragment bundles which need to attach to the
spring-dm bundles. For this to be successful you need to make sure those
fragment-bundles are started before the spring-dm bundles. You're able to
achieve this with startlevels.
regards, Achim
2014-05-19 19:47 GMT+02:00 constv <cv...@healthedge.com>:
> Achim Nierbeck wrote
> > 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
>
> Hi Achim,
> would that imply using spring-dm as a compile dependency vs. the one
> provided by Karaf?
>
> Clearly, using only Blueprint is the safest and cleanest way. It's just too
> bad that with that we lose all the power of Spring configuration
> (annotations, primarily), and we'd have to go back to "manually" wiring
> everything via XML in Blueprint. The Blueprint Annotations project is far
> from being mature and reliable, it seems. Also, I wouldn't want my Java
> code
> to be OSGi-specific, while it is perfectly fine to have Spring dependencies
> in the code since Spring has pretty much been enterprise Java standard for
> years.
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033184.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
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
Re: Spring 4.0.2 and spring-dm
Posted by constv <cv...@healthedge.com>.
Achim Nierbeck wrote
> 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
Hi Achim,
would that imply using spring-dm as a compile dependency vs. the one
provided by Karaf?
Clearly, using only Blueprint is the safest and cleanest way. It's just too
bad that with that we lose all the power of Spring configuration
(annotations, primarily), and we'd have to go back to "manually" wiring
everything via XML in Blueprint. The Blueprint Annotations project is far
from being mature and reliable, it seems. Also, I wouldn't want my Java code
to be OSGi-specific, while it is perfectly fine to have Spring dependencies
in the code since Spring has pretty much been enterprise Java standard for
years.
--
View this message in context: http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033184.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Spring 4.0.2 and spring-dm
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,
good that it works with Spring 3 :), at least this can be the basis of some
Discussion and or development and might take some pressure of this part of
the project ;)
regarding the camel part, for simplification (and again to reduce the
spring-dependencies) I'd switch that part over to Blueprint.
Just one thing to get of the list and less to worry about.
regards, Achim
2014-05-19 14:27 GMT+02:00 constv <cv...@healthedge.com>:
> Achim and Tim, thank you for your help!
>
>
> Achim Nierbeck wrote
> > 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 :)
>
> Yes, I always use JavaDSL to define Camel routes. In Spring configuration,
> I
> simply define camelContext <package> to enable package scanning for route
> builders.
>
> Achim,
> I will investigate/try some of the options you are suggesting. Everything
> seems to work with Spring 3, and if I can use that, it seems to be the
> easiest option. But if I have to use Spring 4 (which may be the client's
> requirement) I'd have to find ways to work around it as you have suggested.
> Thanks again for taking the time to help!!
>
>
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033179.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
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
Re: Spring 4.0.2 and spring-dm
Posted by constv <cv...@healthedge.com>.
Achim and Tim, thank you for your help!
Achim Nierbeck wrote
> 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 :)
Yes, I always use JavaDSL to define Camel routes. In Spring configuration, I
simply define camelContext <package> to enable package scanning for route
builders.
Achim,
I will investigate/try some of the options you are suggesting. Everything
seems to work with Spring 3, and if I can use that, it seems to be the
easiest option. But if I have to use Spring 4 (which may be the client's
requirement) I'd have to find ways to work around it as you have suggested.
Thanks again for taking the time to help!!
--
View this message in context: http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033179.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Spring 4.0.2 and spring-dm
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <cv...@healthedge.com>:
> 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.
>
Re: Spring 4.0.2 and spring-dm
Posted by constv <cv...@healthedge.com>.
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.
Re: Spring 4.0.2 and spring-dm
Posted by Achim Nierbeck <bc...@googlemail.com>.
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
sent from mobile device
Am 16.05.2014 16:21 schrieb "constv" <cv...@healthedge.com>:
> Why do I need Spring? Do you mean for the DI wiring, or in general? ;)
> Lots
> of our application code/services have been developed with Spring, Spring
> has
> been used not only for DI, but for many other things, of course. I, of
> course, understand that the traditional Spring framework (not Spring-DM) is
> not for OSGi, and Blueprint is. However, lots of our code (originally
> developed as part of non-OSGi projects) uses Spring annotations,
> configuration, and many other Spring libraries, e.g data access support,
> AOP, REST, etc. Are you suggesting dropping Spring all together if we want
> to OSGi-enable our applications? Or just not to use it for DI? I
> understand
> that I can use Blueprint for DI and still keep using Spring libraries. As a
> DI framework, Blueprint provides just a subset of the features Spring
> provides, so I'd have to refactor much of the existing stuff. Most of my
> individual bundles are self-contained services, so it would be a shame to
> butcher them just to make the container happy. Don't you think?
>
> Generally, I have only one common bundle that needs to export its
> definitions to be shared with other bundles. So I am using Blueprint in
> that
> bundle to define a number of services that are exported via the OSGi
> service
> registry. Then, my other bundles (mostly, the original non-OSGi
> Spring-wired
> stuff) need to use these services by importing them using spring-dm. I
> don't
> want to have to re-do the whole Spring configuration for these bundles.
> This
> approach has worked before, but I am no able to get this to work in Karaf 3
> with Spring 4 and spring-dm 1.2.1.
>
> Nevertheless, I am open to suggestions, and if the only reliable way is to
> use Blueprint for bean configuration - in the bundles that import
> OSGi-shared references, I guess I'd have to consider that.
>
> So, my question is: does Karaf NOT guarantee seamless integration/support
> for Spring/Spring-dm-configured bundles?
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033139.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
Re: Spring 4.0.2 and spring-dm
Posted by constv <cv...@healthedge.com>.
Why do I need Spring? Do you mean for the DI wiring, or in general? ;) Lots
of our application code/services have been developed with Spring, Spring has
been used not only for DI, but for many other things, of course. I, of
course, understand that the traditional Spring framework (not Spring-DM) is
not for OSGi, and Blueprint is. However, lots of our code (originally
developed as part of non-OSGi projects) uses Spring annotations,
configuration, and many other Spring libraries, e.g data access support,
AOP, REST, etc. Are you suggesting dropping Spring all together if we want
to OSGi-enable our applications? Or just not to use it for DI? I understand
that I can use Blueprint for DI and still keep using Spring libraries. As a
DI framework, Blueprint provides just a subset of the features Spring
provides, so I'd have to refactor much of the existing stuff. Most of my
individual bundles are self-contained services, so it would be a shame to
butcher them just to make the container happy. Don't you think?
Generally, I have only one common bundle that needs to export its
definitions to be shared with other bundles. So I am using Blueprint in that
bundle to define a number of services that are exported via the OSGi service
registry. Then, my other bundles (mostly, the original non-OSGi Spring-wired
stuff) need to use these services by importing them using spring-dm. I don't
want to have to re-do the whole Spring configuration for these bundles. This
approach has worked before, but I am no able to get this to work in Karaf 3
with Spring 4 and spring-dm 1.2.1.
Nevertheless, I am open to suggestions, and if the only reliable way is to
use Blueprint for bean configuration - in the bundles that import
OSGi-shared references, I guess I'd have to consider that.
So, my question is: does Karaf NOT guarantee seamless integration/support
for Spring/Spring-dm-configured bundles?
--
View this message in context: http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033139.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Spring 4.0.2 and spring-dm
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,
just a quick question, cause I think you never pointed to that before.
But why do you need spring again?
Especially since you mentioned camel/spring. If you want to run Camel on
Karaf I strongly
suggest to use blueprint instead of Spring and at that point most of you
headaches will be gone :)
If you want to know how a setup of this might look, take a look at [1]
regards, Achim
[1] - https://github.com/ANierbeck/Camel-Pax-Exam-Demo
2014-05-14 16:48 GMT+02:00 constv <cv...@healthedge.com>:
> Achim, thank you for your reply. In fact, I have tried deploying my
> application using just features, no KAR, and, indeed, was able to make it
> deploy without errors. However, I can't 100% pin-point and consistently
> recreate the sequence of steps required to get it to work. I wipe out the
> Data folder, start from the clean slate, and sometimes it works, sometimes
> it gives me the same error. One thing I know, the only times when it
> actually worked, I used Spring 3.2.4.RELEASE (as the provided dependency
> for
> my application bundles), manually uninstalled the Spring 4.0.2.RELEASE_1
> feature and installed Spring 3.2.4.RELEASE in Karaf. At this point, I am
> sure I can eventually figure out how to manually deploy everything, it is
> just too frustrating that I have to spend more time on fighting with Karaf
> than on the development of my application. Makes me think that it totally
> defeats the purpose of using Karaf/OSGi, in the first place...
>
> Nevertheless, even if I can deploy my features with manual Karaf config
> tweaking, that's not going to satisfy my Prod requirements. The Prod
> environment has no access to any public or local Maven repositories, and it
> is desirable to have a self-contained archive that an admin would drop into
> the container and "forget about it". So, I would really like to understand
> which core Karaf features must be available and activated (and which must
> be
> disabled, if any) to ensure that my [fairly simple] Camel/Spring
> 4.0.2/Spring-DM application deploys as a KAR without the above errors.
> Note
> that the error states:
>
> *Caused by:
> org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
> Configuration problem: Unable to locate Spring NamespaceHandler for XML
> schema namespace [http://www.springframework.org/schema/osgi-compendium] *
>
> It seems as if some Spring bundle(s) are not being started properly, even
> although I explicitly install spring/spring-dm features and see that the
> features are marked with "x" (installed). I don't see any spring bundles in
> the bundles 'list', but that's ok, right?
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033115.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
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
Re: Spring 4.0.2 and spring-dm
Posted by constv <cv...@healthedge.com>.
Achim Nierbeck wrote
> Hi,
>
> From your description I still can't see your issue. Maybe you should tell
> us more about what you are up to.
> Are you trying to run multiple spring versions with spring-dm?
> How is your setup?
> Do you only manually install the spring feature. Do you reference the
> desired spring feature in your feature.xml?
>
> Regards, Achim
I am not using multiple versions of Spring. Originally I was trying to use
the out-of-the-box spring 4.0.2 and spring-dm versions provided by the
container. In my features.xml I have tried including the following:
<feature version="${spring.version}">spring</feature>
<feature version="${spring-dm.version}">spring-dm</feature>
where the versions match the ones provided by Karaf, as well as the same
definitions without the versions (which I believe would have the same effect
of activating spring-dm 1.2.1 and Spring 4.0.2.RELEASE_1).
In both cases I get the exception I have posted in the original question.
If I do:
<feature version="3.2.4.RELEASE">spring</feature>
instead, and - before installing my application feature - make sure that
Spring 4.0.2.RELEASE_1 is UNINSTALLED, the bundle deploys without errors and
the spring context is instantiated.
--
View this message in context: http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033143.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Spring 4.0.2 and spring-dm
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,
>From your description I still can't see your issue. Maybe you should tell
us more about what you are up to.
Are you trying to run multiple spring versions with spring-dm?
How is your setup?
Do you only manually install the spring feature. Do you reference the
desired spring feature in your feature.xml?
Regards, Achim
sent from mobile device
Am 16.05.2014 02:22 schrieb "constv" <cv...@healthedge.com>:
> Okay, for all it's worth, here's what I have figured out. In order for my
> application (that uses Spring + both Blueprint and Spring-DM configuration
> in different bundles) to deploy in Karaf 3, I have to ensure that
>
> a) I am using the Spring 3.2.4.RELEASE (as the spring feature provided by
> Karaf)
> b) Ensure that Spring 4.0.2.RELEASE_1 (Karaf 3 feature) is NOT
> installed/not
> active.
>
> This doesn't seem right, unless I am missing something. But even if I am
> missing something here, shouldn't there be an easy, straightforward way of
> using any version of Spring (or any library, for that matter) without the
> container getting in the way? It seems to me that Karaf/OSGi aims to solve
> some real problems by, unfortunately, imposing a ton of other problems and
> clunky complexities (with sparse documentation), and the solution often
> becomes a problem...
>
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033116.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
Re: Spring 4.0.2 and spring-dm
Posted by constv <cv...@healthedge.com>.
Okay, for all it's worth, here's what I have figured out. In order for my
application (that uses Spring + both Blueprint and Spring-DM configuration
in different bundles) to deploy in Karaf 3, I have to ensure that
a) I am using the Spring 3.2.4.RELEASE (as the spring feature provided by
Karaf)
b) Ensure that Spring 4.0.2.RELEASE_1 (Karaf 3 feature) is NOT installed/not
active.
This doesn't seem right, unless I am missing something. But even if I am
missing something here, shouldn't there be an easy, straightforward way of
using any version of Spring (or any library, for that matter) without the
container getting in the way? It seems to me that Karaf/OSGi aims to solve
some real problems by, unfortunately, imposing a ton of other problems and
clunky complexities (with sparse documentation), and the solution often
becomes a problem...
--
View this message in context: http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033116.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Spring 4.0.2 and spring-dm
Posted by constv <cv...@healthedge.com>.
Achim, thank you for your reply. In fact, I have tried deploying my
application using just features, no KAR, and, indeed, was able to make it
deploy without errors. However, I can't 100% pin-point and consistently
recreate the sequence of steps required to get it to work. I wipe out the
Data folder, start from the clean slate, and sometimes it works, sometimes
it gives me the same error. One thing I know, the only times when it
actually worked, I used Spring 3.2.4.RELEASE (as the provided dependency for
my application bundles), manually uninstalled the Spring 4.0.2.RELEASE_1
feature and installed Spring 3.2.4.RELEASE in Karaf. At this point, I am
sure I can eventually figure out how to manually deploy everything, it is
just too frustrating that I have to spend more time on fighting with Karaf
than on the development of my application. Makes me think that it totally
defeats the purpose of using Karaf/OSGi, in the first place...
Nevertheless, even if I can deploy my features with manual Karaf config
tweaking, that's not going to satisfy my Prod requirements. The Prod
environment has no access to any public or local Maven repositories, and it
is desirable to have a self-contained archive that an admin would drop into
the container and "forget about it". So, I would really like to understand
which core Karaf features must be available and activated (and which must be
disabled, if any) to ensure that my [fairly simple] Camel/Spring
4.0.2/Spring-DM application deploys as a KAR without the above errors. Note
that the error states:
*Caused by:
org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: Unable to locate Spring NamespaceHandler for XML
schema namespace [http://www.springframework.org/schema/osgi-compendium] *
It seems as if some Spring bundle(s) are not being started properly, even
although I explicitly install spring/spring-dm features and see that the
features are marked with "x" (installed). I don't see any spring bundles in
the bundles 'list', but that's ok, right?
--
View this message in context: http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033115.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Spring 4.0.2 and spring-dm
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,
Before running this with a KAR I'd start with using a feature only first.
For example install the needed features with the she'll per command. After
that, install your feature also via command. If this succeeds try with
adding dependencies to your feature and install your feature only via
command. After this works try with a KAR.
regards, Achim
sent from mobile device
Am 12.05.2014 20:33 schrieb "constv" <cv...@healthedge.com>:
> Actually, spoke too soon. The bundles deploy without errors, but no Spring
> context is initialized in any of the bundles at all! Crying for help...
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033096.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
Re: Spring 4.0.2 and spring-dm
Posted by constv <cv...@healthedge.com>.
Actually, spoke too soon. The bundles deploy without errors, but no Spring
context is initialized in any of the bundles at all! Crying for help...
--
View this message in context: http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033096.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Spring 4.0.2 and spring-dm
Posted by constv <cv...@healthedge.com>.
It seems the only way to make theh application deploy was to:
1) Uninstall the container-provided spring-dm feature;
2) Include the spring-osgi-extender as a compile-scoped dependency (not
PROVIDED by the container), e.g.
<dependency>
<groupId>org.springframework.osgi</groupId>
<artifactId>spring-osgi-extender</artifactId>
<version>${spring-osgi.version}</version>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>org.springframework.core</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>org.springframework.aop</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>org.springframework.beans</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>org.springframework.context</artifactId>
</exclusion>
</exclusions>
</dependency>
This just doesn't seem right to me. Isn't there a better way? If Karaf
provides both spring-dm (v1.2.1 - the same version as the one I am using in
my Maven configuration for spring-osgi-extender) and Spring 4, why would the
container not recognize things appropriately? It just seems too clumsy and
ugly. I shouldn't be packaging spring-osgi-extender in each bundle.
Could someone please explain: is the the Karaf flaw, or am I not doing
something correctly? And if it's he latter, where is it documented? Can
anything be easy and intuitive with OSGi? ;-)
--
View this message in context: http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093p4033095.html
Sent from the Karaf - User mailing list archive at Nabble.com.