ApplicationContext ctx = new ClasspathApplicationContext("example.xml");
BeanEx beanEx = (BeanEx)ctx.getBean("beanEx");

public class Activator implements BundleActivator {
 
    static ForumAuthenticationService forumService;
 
    static BundleContext bundleContext;
 
    public void start(BundleContext bundleContext) throws Exception {
        Activator.bundleContext = bundleContext;
    }
 
    public void stop(BundleContext arg0) throws Exception {
        forumService = null;
 
    }
 
    public static ForumAuthenticationService getAuthenticationService() {
        if (forumService == null) {
            OsgiBundleXmlApplicationContext context = new OsgiBundleXmlApplicationContext(
                    new String[] { "META-INF/spring/forum-context.xml" });
            context.setBundleContext(bundleContext);
            context.refresh();
            forumService = (ForumAuthenticationService) context
                    .getBean("forumAuthenticationService");
        }
 
        return forumService;
    }
 
}

2 Responses to “How to invoke Spring beans in other osgi bundle”

1. Costin Leau says:

   May 7, 2009 at 1:18 pm

   The activator should return as fast as possible since otherwise the entire OSGi platform waits for it. Moreover, why would you want to get a hold of the bean in the activator? Any work done with it, will slow down the OSGi platform even more.

   While the solution proposed above works, it has several nasty side effects. There are other alternatives such as:

   - wrapping the context creation in a separate thread so the activator returns fast
   - lookup the ApplicationContext (as Spring DM publishes as a service upon completion) and then use it – of course, also within a separate thread

   In all cases though you would have to pay attention to all possible outcomes, such as the context failing and thus not being published or Activator/OSGi platform shutdown.
   It’s considerably much more easier to leave the Spring DM extender to deal with these issues and simply make your own application IoC’ed rather then using dependency lookup.

   Hope this helps,
2. admin says:

   May 7, 2009 at 6:17 pm

   Thanks Costin,

   The above solution is raised when we need to call spring bean service from a normal java class (a legacy application that it is not managed by Spring).

   The above code sample does a trick and it does not impact the time of initiating Activator because the static method getAuthenticationService is called after Activator start and Spring extender resolves dependencies (We control such flow in our calling function) – and we also handle the possible failures in calling method (in case we can not create the Spring context).

   One thing makes me feel uncomfortable is create the static variable bundleContext (it is a trick to set bundleContext later when create OsgiBundleXmlApplicationContext). Later our implementation, base on the fact that Spring DM registers Spring bean as Osgi service, we use the white board pattern to track whether some Osgi service (Spring bean) is resolved by Spring extender and we catch it.