CODEWITHSUNDEEP
javaspringunit-testingosgiintegration-testing
Marc-Christian Schulze
Marc-Christian Schulze

Reputation: 3264

Spring Application Context can't load the configuration files

I got 2 projects. A plugin project containing some components (POJOs) and a fragment project containing the according unit and integration tests. I'm using Tycho to build these projects and I want to use Spring to bootstrap my integration tests.

I've annotated my test classes with

@ContextConfiguration(locations = { "classpath*:spring/*-config.xml" })
@RunWith(SpringJUnit4ClassRunner.class)

But when I try to build the projects with tycho (clean install) or run the test class as Plugin-Test within eclipse, Spring complains that there are no beans in the context defined. In the log I found the following lines:

DEBUG o.s.t.c.s.AbstractGenericContextLoader - Loading ApplicationContext for 
      locations [classpath*:spring/*-config.xml].
DEBUG o.s.b.f.xml.XmlBeanDefinitionReader - Loaded 0 bean definitions from 
      location pattern [classpath*:spring/*-config.xml]

I've put the configuration files under src/main/java/spring/ and src/main/resources/spring but spring can't find them. I've also tried to add these paths explicit to the bundle-classpath in the manifest.

When I change the configuration path to "file:spring/some-config.xml" spring is loading my bean definitions but crashes when it tries to load the "context" schema with the following output:

Configuration problem: Unable to locate Spring NamespaceHandler for XML schema
namespace [http://www.springframework.org/schema/context]

Why is it not working with the classpath prefix? And why is it working with the file prefix? I thought the file prefix would only work for the file system and not for a jar file... What am I doing wrong?

Thanks in advance

Update: Here is a complete view of the (fragment) test project:

/
+-- src/main/java/
|   +-- MyTestClass.java
|
+-- src/main/resources/
|   +-- spring/
|   |   +-- some-config.xml
|   +-- log4j.properties
|
+-- META-INF/
|   +-- MANIFEST.MF
|
+-- pom.xml

After tycho has tried to execute my test class I see the following files under target:

/target
|
+-- classes/
    +-- MyTestClass.class
    +-- spring/
        +-- some-config.xml
    +-- log4j.properties
+-- work/   // contains the eclipse configuration (config.ini, etc.)
+-- MANIFEST.MF
+-- mybundle-xx.jar

I've ommitted the properties and surfire files. The generated config.ini under target/work/configuration/ lists all bundles that are mentioned in the manifest as required bundles. They are referenced as jar files except of my test fragment bundle. For the test bundle the following entry exists:

reference\:file\:C\:/[...]/workspaces/workspace/my.bundle.tests

Is this correct? It would at least explain why the file prefix is working... But what about the classpath prefix? Has the manifest been copied to the right location in the target folder? I mean it's outside of the classes folder that is referenced in the dev.properties.
Furthermore log4j complains at startup that it's not properly configured which indicates that it can't find the log4j.properties on the classpath.

Update: Now I'm trying another way. I've read this article and it seemed to be an easier way to get things running. So I've added the maven-surfire-plugin to my pom and changed my packaging type from "eclipse-test-plugin" to "jar" so that tycho doesn't run it's own surefire-plugin. But now I'm standing in front of another problem. Spring seems to provide only an ArtifactLocator for maven2 repositories and not for p2 repositories like tycho uses.
Does anyone know if there is an ArtifactLocator for p2 repositories out there?

Is anyone using the same setup with tycho, osgi and spring for integration testing?

Upvotes: 0

Views: 7208

Answers (2)

FelixJongleur42
FelixJongleur42

Reputation: 950

Using Tycho, according to http://blog.vogella.com/2010/07/06/reading-resources-from-plugin/ I tried locations like:

"platform:/plugin/<host-bundle-id>/<path-to-resource>"

and now its able to load the context configurations as a resource.

Upvotes: 0

Bozho
Bozho

Reputation: 597342

Put spring-context-xx.jar on your classpath.

Namespaces are handled by implementations of the NamespaceHandler interface. At startup spring loads all of them, and attempts to parse each namespace with the loaded handlers. If none of them claims to be able to parse it, the exception is thrown. the context: namespace is parsed by ContextNamespaceHandler, which resides in the aforementioned jar.

Upvotes: 1

Related Questions