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

Answer 1

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?