Combine OSGi blueprint and spring configuration

blueprint-osgi, osgi, spring, spring-dm

Solution

Which XML files do you use? Where do you put them in your OSGi bundles (META-INF/spring, OSGi-INF)? Which of these practices will allow you to reuse your bundles in combination with a non-Gemini-implementation of Blueprint?

Gemini Blueprint treats both of these directories equally, but `OSGI-INF/blueprint/*.xml` is the only one specified in the generic OSGi Blueprint specification.

A suggested practice from the Gemini Blueprint documentation is:

[...] A suggested practice is to split the application context configuration into at least two files, named by convention modulename-context.xml and modulename-osgi-context.xml. The modulename-context.xml file contains regular bean definitions independent of any knowledge of OSGi. The modulename-osgi-context.xml file contains the bean definitions for importing and exporting OSGi services. It may (but is not required to) use the Gemini Blueprint OSGi schema as the top-level namespace instead of the Spring 'beans' namespace.

I tried this, and it works great. I use Gemini Blueprint for one of my projects which has the files `META-INF/spring/context.xml`, which defines my beans and their relationships, and `META-INF/spring/osgi-context.xml`, which defines which beans to expose as/import from OSGi services and how. `context.xml` looks like

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
    <bean id="myOrdinarySpringBean" class="com.acme.impl.Foo"/>
</beans>

and is a regular ordinary Spring application context with no Blueprint/OSGi configuration at all. `osgi-context.xml` looks like

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
    <service id="myOsgiService" ref="myOrdinarySpringBean" interface="com.acme.Foo"/>
</blueprint>

You could, of course, use the `<beans>` namespace and root element here as well, but you'd have to define a `xmlns:osgi` and prefix the service like so: `<osgi:service .../>` for that to work. In my case I don't need the Gemini specific Blueprint stuff, so I'm happy with this generic Blueprint configuration. Likewise, I could use the `<blueprint>` namespace in `context.xml` as well, but this particular application is an old one being ported to OSGi, so I prefer to keep that configuration Spring specific for now.

Another application in turn has its own `osgi-context.xml` like

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
  <reference id="myOrdinarySpringBeanImportedFromOsgi" interface="com.acme.Foo" availability="mandatory"/>
</blueprint>

and at this time doesn't, but could, have its own `context.xml` like

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
    <bean id="myOrdinaryOtherSpringBean" class="com.acme.impl.Bar">
        <property name="foo" ref="myOrdinarySpringBeanImportedFromOsgi"/>
    </bean>
</beans>

and couldn't really care less whether `myOrdinarySpringBeanImportedFromOsgi` is imported from an OSGi service or defined as a regular ordinary Spring bean in the same application context.

These `META-INF/osgi-context.xml` configurations could trivially be moved to `OSGI-INF/blueprint/` if I want to decouple yourself from the Gemini Blueprint implementation, but for the time being I prefer to keep the two halves in the same place to avoid making a mess of the directory structure.

Problem

Original source