整体方法

在Apache Sling中进行依赖注入的最简单方法是在整个代码库中使用，它是使用maven-scr-
plugin。

您可以注释Java类，然后在构建时以Maven插件或Ant任务的形式调用SCR插件。

例如，要注册一个servlet，您可以执行以下操作：

@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    
}

具体答案

声明式服务与Guice或Spring这样的“传统” DI相比如何？他们是解决相同的问题还是针对不同的问题？

他们解决了相同的问题-依赖注入。但是（请参阅下文）它们的构建还考虑到了动态系统，服务可以随时出现或消失。

到目前为止，我所看到的所有特定于OSGI的解决方案都缺少DI范围的概念。例如，Guice + guice-
servlet具有请求范围内的依赖关系，这使得编写Web应用程序真正干净和容易。我只是在文档中错过了吗，还是这些框架中没有涵盖这些问题？

在SCR世界中，我还没有看到任何添加会话范围或请求范围服务的方法。但是，SCR是一种通用方法，可以在更特定的层上处理作用域。

由于您使用的是Sling，因此我认为几乎不需要会话作用域或请求作用域的绑定，因为Sling为每个请求都有为当前用户适当创建的内置对象。

一个很好的例子是JCR会话。它是使用正确的权限自动构造的，实际上它是请求范围的DAO。Sling resourceResolver也是如此。

如果发现自己需要按用户进行工作，最简单的方法是让服务接收JCR Session或Sling
ResourceResolver并使用这些服务来执行所需的工作。结果将自动调整为当前用户的特权，而无需任何额外的努力。

JSR 330和基于OSGI的DI是两个不同的世界吗？例如，iPOJO带来了自己的注释，而Felix SCR注释似乎是一个完全不同的世界。

是的，他们不同。您应该记住，尽管Spring和Guice成为主流，但OSGi服务更加复杂并支持更多用例。在OSGi中，捆绑包（和隐式服务）可随时自由往返。

这意味着，当您拥有依赖于刚刚变得不可用的服务的组件时，您的组件将被停用。或者，当您收到组件列表（例如Servlet实现）并且其中之一被停用时，系统会通知您。据我所知，Spring和Guice都不支持这一点，因为它们的接线是静态的。

OSGi为您提供了极大的灵活性。

是否有人有构建基于OSGI的系统和DI的经验？也许甚至在github上有一些示例代码？

Sling Samples
SVN存储库中有大量示例。您应该在那里找到大部分所需的东西。

有人会同时使用Guice和iPOJO等不同的技术吗？或者这只是一个疯狂的想法？

如果您的框架配置有JSR
330批注，那么在运行时使用Guice或Spring或任何适合您的配置对它们进行配置确实很有意义。但是，正如尼尔·巴特利特（Neil
Bartlett）所指出的那样，这不能跨捆绑使用。