OSGi and @Configurable

I have some problems with @Configurable used together with Spring-DM under Equinox (in an RCP application). I'd like to inject a reference pointing to a bean referenced using osgi:reference (sensorConfigProvider) into a bean not instantiated by Spring (SensorView), but it does not work.
My config:

<context:annotation-config/>

<context:spring-configured/>

<osgi:reference id="sensorConfigProvider" interface="configprovider.ISensorConfigProvider" />

<bean class="ui.SensorView"/>

and the class definition:

@Configurable
public class SensorView extends ViewPart {

@Autowired
private ISensorConfigProvider sensorConfigProvider;

...
}

Am I missing something?

How are you applying the aspect? LTW or build time? If you're using LTW have made sure you've got the correct parameters?

have a look at my blog which does the @Configurable stuff
www.amin-mc.blogspot.com

Thanks, Amin. Your blog entry is clear, but I did more or less the same and it does not work.
Additionally, I got an exception:

org.springframework.beans.factory.BeanDefinitionSt oreException: Unexpected exception parsing XML document from URL [bundleentry://39/META-INF/spring/beans.xml];
nested exception is java.lang.IllegalArgumentException: pattern matching is unsupported for class space lookups

So again,

beans.xml:

<context:annotation-config />
<context:spring-configured />
<context:load-time-weaver />
<context:component-scan base-package="acme.sensors" />

<osgi:reference id="sensorConfigProvider" interface="acme.sensors.configprovider.ISensorConf igProvider" />

<bean class="acme.sensors.ui.SensorView"/>

startup parameters:

"C:\Program Files\Java\jdk1.6.0_03\bin\java.exe" -Xbootclasspath/a:lib/aspectjrt.jar -javaagent:lib/spring-agent.jar -jar plugins\org.eclipse.equinox.launcher_1.0.100.v2007 1211.jar -console -consolelog -configuration configuration

bean:

@Configurable(dependencyCheck=true)
public class SensorView extends ViewPart {

public static final String ID = "SensorConfigUi.sensorView";

@Autowired
private ISensorConfigProvider sensorConfigProvider;

...
}

Hmmm...

I'm not sure to be honest. This looks more of an OSGi configuration. I'll need to have a look. I might try to replicate your problem with a test app.

Given how the load time weaver works and the dynamic nature of OSGi I would imagine its possible at the time that the code gets woven, the ISensorConfigProvider service isn't available. What happens if you use a normal Spring bean that implements ISensorConfigProvider using some sort of stub implementation? If that works, but the osgi doesn't, then perhaps a post in the OSGi forum would be in order.

It sounds like it should work because you'd figure that when the osgi reference is made a proxy implementing the interface is created.

As for the XML error, it sounds like there is something wrong with the header of your XML. Can you post it?

I've tried using plain Spring beans without OSGi references, but I got the same.

The headers of my beans.xml:

<?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:osgi="http://www.springframework.org/schema/osgi"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schem...-beans-2.0.xsd
http://www.springframework.org/schema/osgi http://www.springframework.org/schem...pring-osgi.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">

The exception is thrown when I use the <context:component-scan ...> tag.

Looks pretty standard. Eliminating all remnants of osgi from the XML file could help narrow things down. Could be a bad interaction between osgi and context schemas. Or not.

Quote:

---

Originally Posted by wpoitras

Looks pretty standard. Eliminating all remnants of osgi from the XML file could help narrow things down. Could be a bad interaction between osgi and context schemas. Or not.

---

I've tried it, but the problem remains. All the references marked with @Autowired is null.

My modified config:

<bean id="sensorConfigProvider" class="acme.sensors.configprovider.SensorConfigPro vider" scope="singleton"
init-method="init">
<property name="listenerAddress" value="localhost"/>
<property name="listenerPort" value="2244"/>
</bean>

<context:annotation-config />
<context:load-time-weaver aspectj-weaving="on" />
<context:spring-configured />

<bean class="acme.sensors.ui.SensorView"/>
<bean class="acme.sensors.ui.ConfigView"/>

class:

@Configurable
public class SensorView extends ViewPart {

@Autowired
private ISensorConfigProvider sensorConfigProvider;

...
}

startup script:

"C:\Program Files\Java\jdk1.6.0_03\bin\java.exe" -Xbootclasspath/a:lib/aspectjrt.jar -javaagent:lib/spring-agent.jar -jar plugins\org.eclipse.equinox.launcher_1.0.100.v2007 1211.jar -console -consolelog -configuration configuration

I had the same problem and resolved it by defining the bean in the config xml file and removing the @Repository (which is similar to @Component). Defining the bean in the config xml without also removing the @Repository annotation did not resolve the problem.

Annotation scanning was addressed in Spring-DM 1.1.0. M1 has been released while M2 is scheduled for end of April, beginning of May.
The generic problem is that scanning relies on classpath pattern matching which is quite difficult inside an OSGi environment since there is no file system and there can be multiple spaces to search into (as the classes can be in other bundles that are imported into the main one).
Note that currently meta-annotations scanning (@Component) work if you're using Spring 2.5.4 (not released yet) due to a subtle class loading problem that was fixed in HEAD.
Cheers,