我喜欢Guice非常直接地手动创建自己的模块的方式，每个模块都有自己的代码绑定。另一方面，CDI似乎更多地依赖于魔术而不是程序化访问sest绑定。我错了，或者如何用WELD达到同样的效果。
任何代码示例都将受到赞赏......
我希望使用Guice在http://code.google.com/p/google-guice/上给出的构建器模式样式，以编程方式构建一个模块（Guice术语，我不确定CDI术语）。
我正在构建一个动态系统，我需要能够绑定类型（如接口），常量等，而不仅仅是让Weld动态扫描类路径等并查找和注册类型。我相信CDI是静态的，javax.inject包不包含允许以编程方式将类型绑定到实现的任何接口。
原始问题的基本前提是简单的观察，即注释被烘焙，并且在其中定义的规则有助于无法更改注释器。我最初希望公共访问CDI类路径扫描程序用于构建内部使用定义的相同接口。基本上我说的是，我想要一个允许我读取注释并为容器创建定义的图层。默认提供程序可以是执行现在发生的操作的提供程序，但如果您需要其他策略，则可以执行此操作。
当前方法的一个问题是，不能重复使用具有不同注释的组件（类）来选择不同的协作者。在您跳转之前让我对此声明进行限定，是的，可以通过提供商等来完成，但这会导致更多的工件。应该有一个更简单的方法。
很抱歉，如果这个例子很糟糕，我的用例就会更加复杂，细节也会受到影响，并且需要更长时间的阅读。
想象一下有一个url重写组件，为了论证，它有一些参数，比如
如果您希望使用两个不同的替换规则注入相同的组件，但是使用html清洁器注射器，则卡住了。当然有办法解决这个问题，但他们需要人工制品，这当然是更多的代码。
不幸的是，所有绑定规则都在类而不是实例上，因此每次你要求一个类时，你都会得到几乎相当于实例的实例。
这个问题是在一段时间之前写的，我已经放弃了Weld。我相信它决定魔法如何完成的方式是错误的。我不喜欢这样的事实，即如果没有为我提供控制何时或如何重复此操作的方法，他们会向我发出这种情况。我不喜欢这种不灵活性。
答案 0 :(得分：7)
我经常使用Guice和CDI / Seam2。简短的回答是没有，CDI不支持编程bean定义（'绑定'，就像Guice所说的那样）。
CDI使用声明式方法，容器将自动扫描bean定义。这可以通过“替代”功能在某种程度上进行定制，但它不如Guice的程序化方法（基本上可以做任何事情）灵活。
我的两分钱
我使用两个框架：Guice用于“低级”非企业POJO组件（我没有/需要CDI功能），CDI用于我需要CDI额外功能的任何地方，插入JSF或EJB3的东西。主要是我开始使用Guice作为在“适配器”JVM中获取DI的一种方式，它运行应用程序服务器集群。随着我越来越熟悉CDI，我发现对Guice的需求较少。我认为当CDI支持'非托管'实例时，我可以用CDI替换Guice（例如焊接）。
RE：焊接'魔术' - IMO没有任何关于bean定义扫描的“魔力”。它在CDI规范中确实很明确，它类似于其他Java Enterprise框架，如JPA和EJB3。
我的建议是：