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.

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,