We Keep Coding

Dependency Injection in OSGI environments

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:
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?
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?
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.
Does anybody have experience with building OSGI based systems and DI? Maybe even some sample code on github?
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!

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.

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.

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.

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.

I am using osgi and DI for current my project, I've choosed gemini blueprint because it is second version of SPRING DYNAMIC MODULES, Based on this information I suggest you to read Spring Dynamic Modules in Action. This book will help you to understand some parts and points how to build architecture and why is it good :)

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?

What are the benefits of Spring Framework in Terms of Testing Application?

We have heard a lot about Benefits of Spring like it offers loose coupling, dependency injection, inversion of control etc but from testing point of view, I have couple of question.
What are the advantages of Spring Framework in terms of testing an application?
Why Application developed using Spring as considered my testable as opposed to other Web Application?
Please provide some useful examples as then it would be much more easier to understand explanation. I am new to Spring as such and want to understand precise benefits offered by Spring Framework from Application Developer point of view ?

An application geared towards dependency injection is typically more testable because resources are easily replaced with test-oriented resources. Consider a service object that uses a data access object; in production, you'd inject a DAO that talked to a backend data store. But for each test you could create a DAO that returned specific, known data; this allows you to focus on the object being tested.
Spring is one of many dependency injection frameworks for Java, albeit the most popular; any DI framework is going to give you this kind of benefit.

How advisable is migrating to spring framework?

Currently we have a framework(a customized MVC pattern in flex and command pattern in java) which works well with our use case. we are thinking about migration of our server to spring framework. How advisable it is?. our java framework is also loosely coupled.But I see spring more loosely coupled with some concepts Dependency injection and inversion of control( which i still need to get some idea).Basically in what kind of use-case people use spring.How efficient it is?.if its advisable also please let me know where to start with.

Using a framework like Spring or Guice helps you keep your applications organized and loosely coupled over time. A dependency injection framework essentially extracts object construction away from an application, allowing the application to focus on what it needs to do instead of any architectural concerns.
Another upfront advantage of using dependency injection is that your application no longer worries about object construction, thus allowing you to build mock objects to test each portion of you application independently.
I highly suggest reading Dhanji Prasanna's book Dependency Injection.

One benefit of moving to spring is that new developers you bring on will be more likely to know that tool, and may come up to speed faster.
That being said, rewriting an app needs to require a lot of justification. Is your current architecture failing you for any reason?

uses of spring framework in java

I have read that the main uses of spring is DI and AOP.
As far as i understand spring in 3 weeks , i feel that AOP can be done in aspectj
and DI is technique not specific to spring with API's.
so is i am missing anything. spring only creates beans.
is that it

I have read that the main uses of
spring is DI and AOP.
And the modules and libraries that come with both. Spring is a three-legged stool, in my opinion.
As far as i understand spring in 3
weeks , i feel that AOP can be done in
aspectj
Of course AOP can be done with AspectJ - as long as you don't mind byte code alterations. You can also use Spring's original AOP, which uses proxies and is less invasive.
and DI is technique not
specific to spring with API's.
I'm not sure I understand your point here. The wording isn't very clear. If your point is that DI can be done without Spring, then I'd say you are correct.
so is i am missing anything. spring
only creates beans.
I'd say you're missing everything.
is that it
What else do you want it to do?
What alternative do you prefer?
UPDATE:
I don't know about PHP, but there's a version of Spring for Python: Spring.py. This suggests to me that you can certainly do both DI and AOP in Python. I would say that they're possible in any language that's truly object-oriented. The ideas of DI and AOP are like any other OO pattern: language agnostic.

It is a container and MVC web application framework as well. There is also OSGI support. Spring consists of many parts/modules, which can be integrated with other frameworks such as Hibernate.
http://www.springsource.org/about

Spring is in my opinion a defacto standard when it comes to developing web applications/services, or even general application development.
It provides dependency injection as one of its strongpoints, to offer the conveniance of having all necessary tools in one package.
AoP on the other hand nicely integrates with Spring, but is in no way a fundamental reason to use spring. In fact, I dare to claim that alot of people probably don't explicitly (the underlying framework might still do it for you though). You can probably use spring a lifetime without having to explicitly use AoP.

Can anyone provide a clear explanation of why Google Guice is useful?

I've read about Google Guice, and understand the general issues with other approaches to dependency injection, however I haven't yet seen an example of someone using Guice "in practice" where its value becomes clear.
I'm wondering if anyone is aware of any such examples?

Using Google Guice to provides ease in unit testing is only high-level advantage. Some people might not even use unit testing in their project. People has been using Spring/Dependency Injection more than only for unit testing.
The low level advantage of using Google Guice is a matter of cohesion in your application, your classes in the project can be loosely coupled between each other. I can provide a class for another class without them being dependent to each other.
Consider this example:
public class A {
}
public class B {
A a = new A();
}
Class B would be tightly coupled to Class A, or in other words it is dependent to class A's existence.
But with Guice I can instead make it loosely coupled like this:
public class B {
private A a;
#Inject
public B(A a) {
this.a = a;
}
}
Class B is now loosely coupled to A, and Guice is responsible to provide the instance of A instead of B having to instantiate it. With this you can extend it to provide interface of A to B, and the implementation can be a Mock object if you want to unit test your apps.
Having said that we're only discussing the benefits of Dependency Injection so far. Beyond Dependency Injection, the benefits of using Google Guice is:
Guice has a very clean implementation of constructor Injection. As you can see from the example you just add #Inject annotation constructor.
Guice also has setter Injection using the same annotation.
Having said that, the annotation based Injection is very clean approach compared to XML based injection like some other DI implementation.
All of the dependency injection and configuration is using Java, so you are guaranteed to get a typesafety in your application by default.
Guice has a very lightweight implementation of Aspect Oriented Programming (or maybe you can call it as a wrapper to the AOPAlliance AOP implementation). And the good thing of it is it doesn't generate stubs or what-so-ever.
That's the overview of it. But as you get deeper with Guice, there's so many more good things about it. A simple real life example is if you are using GWT with MVP implementation, the components/widgets in your GWT application are very loosely coupled and not tightly integrated to each other.

Maybe you should go back in time and look closer at the problems Guice wanted to solve. To understand the motivations behind Guice, the Bob Lee: I Don't Get Spring news on TheServerSide.COM (and its comments) is the perfect starting point. Then, go ahead with the announcement of Google Guice, A Java Dependency Injection Framework (and the comments) and the Tech Talk: Bob Lee on Google Guice (and the comments).
Personally, I was sharing concerns about evil XML: XML configuration hell, XML and possible runtime errors, error-prone and refactoring-adverse string identifiers, etc, etc. Actually, I believe that skeptical opinions on Spring and concurrence were good for everybody (including Spring). I was thus happy to see a new player in the DI framework landscape, especially a modern framework leveraging Java 5 features (generics and annotations for the sake of type safety).
And because Google is running Guice in mission critical applications (almost every Java-based application is also a Guice-base application: AdWords, Google Docs, Gmail, and even YouTube as reported by "Crazy" Bob Lee in Guice²), I can't believe Guice is totally wrong and doesn't provide any value. Sadly, I don't think Google will provide much code of these applications as examples... But you may find interesting things in the list of applications that use Guice and/or the list of 3rd party Guice addons. Or check out the books mentioned in Guice². Or ask Bob :)

I think the advantage comes with coding to interfaces, testing, and proxies.
Coding to an interface helps keep your code layered properly, makes it possible to inject mocks for testing, and lets you generate proxies automagically so client code need not worry about implementation.
This is true for Guice, Spring, PicoContainer, and all DI frameworks.
Succinct enough?