Dependency Injection in OSGI environments

Question

First some background:

I'm working on some webapp prototype code based on Apache Sling which is OSGI based and runs on Apache Felix. I'm still relatively new to OSGI even though I think I've grasped most concepts by now. However, what puzzles me is that I haven't been able to find a "full" dependency injection (DI) framework. I've successfully employed rudimentary DI using Declarative Services (DS). But my understanding is that DS are used to reference -- how do I put this? -- OSGI registered services and components together. And for that it works fine, but I personally use DI frameworks like Guice to wire entire object graphs together and put objects on the correct scopes (think @RequestScoped or @SessionScoped for example). However, none of the OSGI specific frameworks I've looked at, seem to support this concept.

I've started reading about OSGI blueprints and iPOJO but these frameworks seem to be more concerned with wiring OSGI services together than with providing a full DI solution. I have to admit that I haven't done any samples yet, so my impression could be incorrect.

Being an extension to Guice, I've experimented with Peaberry, however I found documentation very hard to find, and while I got basic DI working, a lot of guice-servlet's advanced functionality (automatic injection into filters, servlets, etc) didn't work at all.

So, my questions are the following:

1. How do declarative services compare to "traditional" DI like Guice or Spring? Do they solve the same problem or are they geared towards different problems?
2. All OSGI specific solutions I've seen so far lack the concept of scopes for DI. For example, Guice + guice-servlet has request scoped dependencies which makes writing web applications really clean and easy. Did I just miss that in the docs or are these concerns not covered by any of these frameworks?
3. Are JSR 330 and OSGI based DI two different worlds? iPOJO for example brings its own annotations and Felix SCR Annotations seem to be an entirely different world.
4. Does anybody have experience with building OSGI based systems and DI? Maybe even some sample code on github?
5. Does anybody use different technologies like Guice and iPOJO together or is that just a crazy idea?

Sorry for the rather long question.

Any feedback is greatly appreciated.

---

Updates

Scoped injection: scoped injection is a useful mechanism to have objects from a specific lifecycle automatically injected. Think for example, some of your code relies on a Hibernate session object that is created as part of a servlet filter. By marking a dependency the container will automatically rebuild the object graph. Maybe there's just different approaches to that?

JSR 330 vs DS: from all your excellent answers I see that these are a two different things. That poses the question, how to deal with third party libraries and frameworks that use JSR 330 annotations when used in an OSGI context? What's a good approach? Running a JSR 330 container within the Bundle?

I appreciate all your answers, you've been very helpful!

Solution 1

Overall approach

The simplest way to have dependency injection with Apache Sling, and the one used throughout the codebase, is to use the maven-scr-plugin .

You can annotate your java classes and then at build time invoke the SCR plugin, either as a Maven plugin, or as an Ant task.

For instance, to register a servlet you could do the following:

@Component // signal that it's OSGI-managed
@Service(Servlet.class) // register as a Servlet service
public class SampleServlet implements Servlet {   
   @Reference SlingRepository repository; // get a reference to the repository    
}

Specific answers

How do declarative services compare to "traditional" DI like Guice or Spring? Do they solve the same problem or are they geared towards different problems?

They solve the same problem - dependency injection. However (see below) they are also built to take into account dynamic systems where services can appear or disappear at any time.

All OSGI specific solutions I've seen so far lack the concept of scopes for DI. For example, Guice + guice-servlet has request scoped dependencies which makes writing web applications really clean and easy. Did I just miss that in the docs or are these concerns not covered by any of these frameworks?

I haven't seen any approach in the SCR world to add session-scoped or request-scoped services. However, SCR is a generic approach, and scoping can be handled at a more specific layer.

Since you're using Sling I think that there will be little need for session-scoped or request-scoped bindings since Sling has builtin objects for each request which are appropriately created for the current user.

One good example is the JCR session. It is automatically constructed with correct privileges and it is in practice a request-scoped DAO. The same goes for the Sling resourceResolver.

If you find yourself needing per-user work the simplest approach is to have services which receive a JCR Session or a Sling ResourceResolver and use those to perform the work you need. The results will be automatically adjusted for the privileges of the current user without any extra effort.

Are JSR 330 and OSGI based DI two different worlds? iPOJO for example brings its own annotations and Felix SCR Annotations seem to be an entirely different world.

Yes, they're different. You should keep in mind that although Spring and Guice are more mainstream, OSGi services are more complex and support more use cases. In OSGi bundles ( and implicitly services ) are free come and go at any time.

This means that when you have a component which depends on a service which just became unavailable your component is deactivated. Or when you receive a list of components ( for instance, Servlet implementations ) and one of them is deactivated, you are notified by that. To my knowledge, neither Spring nor Guice support this as their wirings are static.

That's a great deal of flexibility which OSGi gives you.

Does anybody have experience with building OSGI based systems and DI? Maybe even some sample code on github?

There's a large number of samples in the Sling Samples SVN repository . You should find most of what you need there.

Does anybody use different technologies like Guice and iPOJO together or is that just a crazy idea?

If you have frameworks which are configured with JSR 330 annotations it does make sense to configure them at runtime using Guice or Spring or whatever works for you. However, as Neil Bartlett has pointed out, this will not work cross-bundles.

Solution 2

I'd just like to add a little more information to Robert's excellent answer, particularly with regard to JSR330 and DS.

Declarative Services, Blueprint, iPOJO and the other OSGi "component models" are primarily intended for injecting OSGi services. These are slightly harder to handle than regular dependencies because they can come and go at any time, including in response to external events (e.g. network disconnected) or user actions (e.g. bundle removed). Therefore all these component models provide an additional lifecycle layer over pure dependency injection frameworks.

This is the main reason why the DS annotations are different from the JSR330 ones... the JSR330 ones don't provide enough semantics to deal with lifecycle. For example they say nothing about:

• When should the dependency be injected?
• What should we do when the dependency is not currently available (i.e., is it optional or mandatory)?
• What should we do when a service we are using goes away?
• Can we dynamically switch from one instance of a service to another?
• etc...

Unfortunately because the component models are primarily focused on services -- that is, the linkages between bundles -- they are comparatively spartan with regard to wiring up dependencies inside the bundle (although Blueprint does offer some support for this).

There should be no problem using an existing DI framework for wiring up dependencies inside the bundle. For example I had a customer that used Guice to wire up the internal pieces of some Declarative Services components. However I tend to question the value of doing this, because if you need DI inside your bundle it suggests that your bundle may be too big and incoherent.

Note that it is very important NOT to use a traditional DI framework to wire up components between bundles. If the DI framework needs to access a class from another bundle then that other bundle must expose its implementation details, which breaks the encapsulation that we seek in OSGi.

Solution 3

I have some experience in building applications using Aries Blueprint. It has some very nice features regarding OSGi services and config admin support.

If you search for some great examples have a look at the code of Apache Karaf which uses blueprint for all of its wiring. See http://svn.apache.org/repos/asf/karaf/

I also have some tutortials for Blueprint and Apache Karaf on my website: http://www.liquid-reality.de/display/liquid/Karaf+Tutorials

In your environment with the embedded felix it will be a bit different as you do not have the management features of Karaf but you simply need to install the same bundles and it should work nicely.

Solution 4

I can recommend Bnd and if you use Eclipse IDE sepcially Bndtools as well. With that you can avoid describing DS in XML and use annotations instead. There is a special Reference annotation for DI. This one has also a filter where you can reference only a special subset of services.

Solution 5

Running into a similar architecture problem here - as Robert mentioned above in his answer:

If you find yourself needing per-user work the simplest approach is to have services which receive a JCR Session or a Sling ResourceResolver and use those to perform the work you need. The results will be automatically adjusted for the privileges of the current user without any extra effort.

Extrapolating from this (and what I am currently coding), one approach would be to add @param resourceResolver to any @Service methods so that you can pass the appropriately request-scoped object to be used down the execution chain.

Specifically we've got a XXXXService / XXXXDao layer, called from XXXXServlet / XXXXViewHelper / JSP equivalents. So managing all of these components via the OSGI @Service annotations, we can easily wire up the entire stack.

The downside here is that you need to litter your interface design with ResourceResolver or Sessions params.

Originally we tried to inject ResourceResolverFactory into the DAO layer, so that we could easily access the session at will via the factory. However, we are interacting with the session at multiple points in the hierarchy, and multiple times per request. This resulted in session-closed exceptions.

Is there a way to get at that per-request ResourceResolver reliably without having to pass it into every service method?

With request-scoped injection on the Service layers, you could instead just pass the ResourceResolver as a constructor arg & use an instance variable instead. Of course the downside here is you'd have to think about request-scope vs. prototype-scope service code and separate out accordingly.

This seems like it would be a common problem where you want to separate out concerns into service/dao code, leaving the JCR interactions in the DAO, analogous to Hibernate how can you easily get at the per-request Session to perform repo operataions?

View more solutions

Comments

[ilikeorangutans]

Hi Sergii, thanks for your advice. I will definitely check out Spring Dynamic Modules. Not sure how I missed that! ;)

[Sergii Zagriichuk]

Start to read from second version called eclipse gemini bluprint eclipse.org/gemini/blueprint

[Bertrand Delacretaz]

Totally agree with Robert here, if you're already using Sling there's no need to add extra layers. Spring or Guice might add a few additional features compared to the OSGi Services Component Runtime, but less moving parts usually translates to systems that are easier to debug and maintain. I would recommend reading the OSGi in Action book (manning.com/hall) to get a good overview of what the standard OSGi services used in Sling bring, out of the box.

[Bertrand Delacretaz]

Bnd is what's used under the hood by the maven-scr-plugin that Robert mentions.

[Bertrand Delacretaz]

As for the Sling samples, I'd recommend looking at the Slingbucks one, which is fairly simple and "modern" in the way it uses the SCR services and annotations - it's at svn.apache.org/repos/asf/sling/trunk/samples/slingbucks . I also have created a simple RESTful server sample for my ApacheCon "OSGi for mere mortals" talk, that you can find at github.com/bdelacretaz/OSGi-for-mere-mortals and uses similar techniques outside of Sling.

[Christian Schneider]

If you want to use Spring DM then use the new gemini. The old spring DM has some severy classloading problems in OSGi as it maintains too much compattibility with the original spring. An alternative is Aries blueprint which is more lightweight than gemini but has less features. See gnodet.blogspot.de/2010/03/…

[ilikeorangutans]

Yes, these I use already. I autogenerate the XML files with Apache Felix' BND plugin.

[ilikeorangutans]

Wow, first of all, thank you for this elaborate answer! I'll try to update the original question with more updates, comments don't seem to be the right place for a lot of updates.

[Richard]

As Robert mentions, scoping methods are domain specific. As such, they should rather be part of the domain specific framework (e.g. web framework) and APIs that pass through the relevant context. In case of Sling that would be the SlingHttpServletRequest (and also the Response) interfaces, which give you access to all things around the request (i.e. pre-built resource resolver + session authenticated with the request user). If needed, pass it along to your services that need those request-specific objects. IMHO mixing that scoping approach with DI just leads to too much "magic" code.

[ilikeorangutans]

Hello Neil, thank you for your answer. My observation is similar to yours, OSGI DI frameworks focus primarily on OSGI services and less on wiring up the object graph. The reason why I'm asking about JSR330 DI is that we already have a lot of code that uses them, so the easiest path would be to drop in Guice and have an injector within the bundle. However, then the question becomes how to expose instances created by Guice via/as OSGI services?

[Neil Bartlett]

Wiring up OSGi services is wiring up the object graph... where that graph crosses module boundaries. If you're going to use something like DS then you could create a Guice "module" (terminology clash!) entirely within the DS component.