CDI(WELD) 中是否有等效的方法来构建定义（如 Guice 模块中所做的那样）然后创建注入器？
我喜欢 Guice 使手动创建自己的模块相当简单，每个模块都有自己的绑定在代码中完成。另一方面，CDI 似乎更多地依赖于魔法而不是对 sest 绑定的编程访问。我错了吗？或者如何使用 WELD 达到相同的效果。
任何代码示例将不胜感激...
澄清
我希望以编程方式构建一个模块（Guice术语抱歉我不确定CDI术语），使用Guice在http://code.google.com/p/google-guice/。
我正在构建一个动态系统，我需要能够绑定类型（如接口）、常量等，而不仅仅是让 Weld 动态扫描类路径等并查找和注册类型。我相信 CDI 是静态的，javax.inject 包不包含任何允许以编程方式将类型绑定到实现的接口。
澄清第 2 部分
最初问题的基本前提是一个简单的观察：注释是内置的，并且注释中定义的用于帮助注入器的规则不能更改。我最初希望公共访问 CDI 类路径扫描器用于构建其内部使用的定义的相同接口。基本上我想说的是，我想要一个允许我读取注释并创建容器定义的层。默认提供程序可能会执行现在发生的操作，但如果您想要其他策略，则存在执行此操作的可能性。
当前方法的一个问题是无法重用具有不同注释的组件（类）来选择不同的协作者。在你开始之前，让我来限定一下这个声明，是的，它可以通过提供者等来完成，但这会导致更多的工件。应该有更简单的方法。
示例1
抱歉，如果这个示例很糟糕，我的用例涉及更多内容，细节会妨碍并需要更长的阅读时间。
想象一下，有一个 url 重写组件，出于参数考虑，它有一些参数，例如
- 用该模式替换该模式。
- 也许是一个 html 清理器
如果您希望使用两个不同的替换规则注入同一个组件，但有 html 清理器注入器，那么您就会陷入困境。当然有一些方法可以解决这个问题，但它们需要人工制品，这当然是更多的代码。
不幸的是，所有绑定规则都在类上，而不是在实例上，因此每次您请求一个类时，您都会返回一个功能相当的实例。
WELD
这个问题是不久前写的，我已经放弃了 Weld。我相信它决定其魔力如何发挥的方式是错误的。我不喜欢这样的事实：他们告诉我这是如何发生的，却没有为我提供一种方法来控制我何时或如何重复此操作。我不喜欢这种不灵活的态度。
I like the way Guice makes it fairly straight forward to manually create your own modules each with their own bindings done in code. CDI on the other hand seems to rely more on magic rather than programmatic access to sest bindings. Am i wrong or how can one achieve the same effect with WELD.
Any code sample would be appreciated...
CLARIFICATION
I was hoping to build a Module(Guice term sorry im unsure of the CDI term) programmatically, using the builder pattern style as given by Guice on http://code.google.com/p/google-guice/.
I am building a dynamic system and there is a need for me to be able to bind types(like interfaces), constants etc rather than just have Weld dynamicaly scan the classpath etc and find and register types. I believe that CDI is static the javax.inject package does not include any interfaces that allow one to programmatically bind types to implementations.
CLARIFICATION PART 2
The basic premise of the original question was the simple observation that annotations are baked in and the rules defined in them to help the inejctor cannot be changed. I originally wanted public access to the same interfaces that the CDI classpath scanner uses to build definitions for its internal use. Basically waht im saying is, i want a layer that allows me to read the annotations and create the definitions for the container. A default provider could be one that does what happens now, but if you want some other strategy then there exists the possibility to do this.
One problem with the current approach is the limitation that one cannot reuse components(classes) with different annotations to select different collaborators. Before you jump let me qualify this statement, yes it can be done with providers and the such but this leads to more artifacts. There should be a simpler way.
Example1
Sorry if this example is poor, my use case is much more involved and the detail would get in the way and make for a much longer read.
Imagine one has a url rewriting component that for arguments sake has some parameters like
- replace this pattern with that pattern.
- maybe a html cleaner
If you wish to inject this same component with two different replace rules but have the html cleaner injector, your stuck. Sure there are ways to get around this but they require artefacts which is of course more code.
All binding rules unfortunately are on the class and not the instance thus every time you ask for a class you get back pretty much afunctionally equivalent instance.
WELD
This question was written a whiel ago, i have given up on Weld.I believe the way it dictates how its magic is done is wrong. I dont like the fact they dictate to me how this happens without providing me a way to control when or how i might want to repeat this action. I dont like this inflexibility.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我定期使用 Guice 和 CDI/Seam2。简短的回答是不，CDI 不支持编程 bean 定义（Guice 称之为“绑定”）。
CDI 使用声明性方法，容器将自动扫描 bean 定义。这可以在某种程度上通过“替代”功能进行定制，但它不像 Guice 的编程方法那么灵活（你基本上可以做任何事情）。
我的两分钱
我都使用两种框架：Guice 用于“较低级别”非企业 POJO 组件（我没有/不需要 CDI 功能），CDI 用于任何我需要 CDI 额外功能的地方，插入 JSF 或 EJB3 的东西。主要是我开始使用 Guice 作为在“适配器”JVM 中获取 DI 的一种方式，这些 JVM 在应用程序服务器集群之外运行。随着我对 CDI 越来越熟悉，我发现对 Guice 的需求越来越少。我想象，当 CDI 支持“非托管”实例时，我也许可以用 CDI 替换 Guice（例如焊接se）。
RE: Weld“魔法”——在我看来，bean 定义扫描没有什么“魔法”。它在 CDI 规范中定义得非常好，并且与其他 Java 企业框架（例如 JPA 和 EJB3）类似。
我给你的建议是：
I use Guice and CDI/Seam2 on a regular basis. The short answer is no, CDI does not support programmatic bean definition ('binding', as Guice calls it).
CDI uses a declarative approach where the container will automatically scan for bean definitions. This can be customized to some extent with the 'alternatives' features, but it's not as flexible as Guice's programmatic approach (where you can do basically anything).
My two cents
I use both frameworks: Guice for "lower level" non-enterprise POJO components (where I don't have/need CDI features), CDI for anything where I need the extra features of CDI, things that are plugged into JSF or EJB3. Mainly I started using Guice as a way to get DI in 'adapter' JVMs, which run ouside of the application server cluster. As I get more familiar with CDI, I'm finding less of a need for Guice though. I imageine that when CDI supports 'unmanaged' instances I may be able to replace Guice with CDI (e.g. weld-se).
RE: Weld 'magic' - IMO nothing is 'magic' about bean definition scanning. It's really well defined in the CDI spec, and it is similar to other Java Enterprise frameworks such as JPA and EJB3.
My advice is to you is: