Yes, OSGi is not officially supported by spring anymore or at least not outside of eclipse virgo… Yes, just use blueprint, if you have no legacy applications and like doing dependency injection as in the good old days with a lot of xml metadata… Or just wait until CDI is an overall supported technology…
In the meantime you have to solve spring related problems :-) I had a working camel cxf spring rest bundle application example that I initialized via the following spring xml configuration: <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:cxf="http://cxf.apache.org/core"; xmlns:camel-cxf="http://camel.apache.org/schema/cxf"; xmlns:camel="http://camel.apache.org/schema/spring"; xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd http://camel.apache.org/schema/cxf http://camel.apache.org/schema/cxf/camel-cxf.xsd http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd";> <cxf:bus> <cxf:features> <cxf:logging/> </cxf:features> </cxf:bus> <camel-cxf:rsServer id="helloService" address="/rs" serviceClass="com.rwe.negotiator.rest.SayHello"/> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring";> <route id="sayHello"> <from uri="cxfrs:bean:helloService"/> <transform> <constant>hello</constant> </transform> </route> </camelContext> </beans> But: The same application does not work anymore with karaf-3.0.2 and cxf-3.0.1. During the start of the application you'll find the following excpeption in the logs: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://cxf.apache.org/core] Offending resource: URL [bundle://297.0:0/META-INF/spring/camel-context.xml] The error has already been discussed in this forum (http://karaf.922171.n3.nabble.com/Spring-4-0-2-and-spring-dm-tp4033093.html), but it did not yield a solution. No it's not a problem with its osgi bundle meta data, like a missing import statement. Spring's OsgiBundleXmlApplicationContext tries to parse the xml configuration file and encounters a few unknown namespaces, like http://camel.apache.org/schema/cxf. To see what is going on here just increase the log level for spring's PluggableSchemaResolver class: karaf@local()> log:set TRACE org.springframework.beans.factory.xml Now the log file tells us, what namespaces spring could resolve, e.g.: TRACE | ExtenderThread-2 | PluggableSchemaResolver | 43 - org.apache.servicemix.bundles.spring-beans - 3.2.11.RELEASE_1 | Trying to resolve XML entity with public id [null] and system id [http://camel.apache.org/schema/cxf/camel-cxf.xsd] DEBUG | ExtenderThread-2 | PluggableSchemaResolver | 43 - org.apache.servicemix.bundles.spring-beans - 3.2.11.RELEASE_1 | Found XML schema [http://camel.apache.org/schema/cxf/camel-cxf.xsd] in classpath: schema/cxfEndpoint.xsd I looked through the complete log file and as it turns out, it didn't find a NamespaceHandler for http://cxf.apache.org/core. It's not a problem with my application, the NamespaceHandler is really missing in karaf, although the cxf-core bundle is installed. karaf@local()> list -t 0 | grep -i cxf 166 | Active | 40 | 3.0.1 | Apache CXF Core So what happend? Every possible spring NamespaceHandler gets registered by the spring-osgi-extender module. This module has a class named NamespaceManager. (By the way the original source code is still available from http://docs.spring.io/downloads/nightly/release-download.php?project=OSGI in the file spring-osgi-1.2.1-with-dependencies.zip from the year 2009) Let's increase the log level for this class in karaf's logging configuration 'org.ops4j.pax.logging.cfg' with this extra line and restart karaf: log4j.logger.org.springframework.osgi.extender.internal.support=DEBUG,out The log file reveals the real problem now: DEBUG | FelixStartLevel | NamespaceManager | 91 - org.springframework.osgi.extender - 1.2.1 | Bundle [Apache CXF Core (org.apache.cxf.cxf-core)] declares namespace handlers but is not compatible with extender [org.springframework.osgi.extender|1.2.1]; ignoring... DEBUG | FelixStartLevel | NamespaceManager | 91 - org.springframework.osgi.extender - 1.2.1 | Bundle [Apache CXF Core (org.apache.cxf.cxf-core)] declares namespace handlers but is not compatible with extender [org.springframework.osgi.extender|1.2.1]; ignoring... Namespace handlers of some bundles just get ignored :-) Inside the source code of this NamespaceManager you find: // check type compatibility between the bundle's and spring-extender's spring version if (hasCompatibleNamespaceType(bundle)) { addHandler(bundle); } else { if (log.isDebugEnabled()) log.debug("Bundle [" + OsgiStringUtils.nullSafeNameAndSymName(bundle) + "] declares namespace handlers but is not compatible with extender [" + extenderInfo + "]; ignoring..."); } So we have a problem if two spring versions are installed in parallel. The spring-osgi-extender module might have imported the spring 3.x packages and cxf-core has imported spring 4.x packages. At the time the extender module scans cxf's NamespaceHandlers it compares if the classloaders are the same inside the hasCompatibleNamespaceType method. Both the osgi-extender bundle and the cxf bundle have a wide version range of spring package imports. None of them explicitly references a specific version. They are just capable of working with all spring versions. At runtime each chooses the highest (I think) version of spring packages that are available. In the end, every module might have imported a different version and are not compatible to each other. As a result not all spring namespace handlers are registered. Everything works perfectly again if you just install only one spring version in karaf. By the way, it's not easy to exclude a spring version, since karaf's spring feature lists them all. It would be great if someone can split the spring-features.xml in multiple files like spring3.2-features and spring-4.0-features, so that you can reference the features repository independently? Is there a real solution to this version hell? Better restrict karaf to install only one spring version? -- View this message in context: http://karaf.922171.n3.nabble.com/spring-s-NamespaceHandler-again-tp4037036.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
