焊接中外部（第 3 方）bean 的解析
我知道它仍然不太受欢迎，因为该规范几个月前才发布。
我还没有“安装”焊接，我只是在阅读，通过这个问题，我想确保我已经正确理解了这一重要点：
是否通过将第三方 jar 中的 bean 声明为来实现解析beans.xml 中？
如果没有，如何使用没有 beans.xml 的第三方库中的 bean？
除非 META-INF 中有 beans.xml ，否则将 jar 放在类路径中将不起作用，而对于 3rd 方 jar 则无法实现这一点。 （请参阅 Gavin King 关于该主题的帖子）
I know it is still not quite popular, since the spec was released just a few months ago.
I haven't "installed" weld yet, I'm just reading, and by this question I want to make sure I've understood this important point correct:
Is resolution of beans that are in 3rd-party jars achieved by declaring them as <alternatives> in your beans.xml?
If not, how to use beans from 3rd party libraries that don't have beans.xml ?
Putting the jar on the classpath won't work unless there is beans.xml in their META-INF, which you can't make true for 3rd party jars. (see Gavin King's post on the subject)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为什么想得这么复杂？
只需为那些第 3 方类创建一个 ProducerMethod 即可。
假设您有一个第三方库，它会自动获取 PDF 文件并按传真发送它们，并且您喜欢
在代码中使用类似的内容，那么您可以简单地使用生成器方法来提供它。 PdfFaxService 工作无状态，因此我们可以放心地假设我们可以将其设为
@ApplicationScoped:某处。
嗯。
why think so complicated?
Simply make a producerMethod for those 3rd party classes.
Let's assume you have a 3rd party library which automatically takes PDF files and sends them per faximile, and you like to use something like
in your code, then you could simply provide this with a producer method. The PdfFaxService works stateless, so we can safely assume that we can make it
@ApplicationScoped:somewhere.
hth.
我对替代方案的理解是，它是可以在不同的部署环境（例如测试环境）中使用的接口的其他实现的替代方案。 alternative bean 是通过使用
@Alternative注释来声明的。要在给定部署场景中使用替代方案，您可以在 CDI 部署描述符
META-INF/beans.xml的启用后，如果容器发现给定注入点的不明确依赖项，它将查看可以注入的替代方案，如果恰好有一个，则选择该替代方案。
换句话说，替代是在部署时用另一个实现替换现有实现的好方法。如果没有什么可替换的，则不需要替代方案，只需将 jar 放在类路径上即可。虽然不确定这正是你的问题，但我对第 3 方 jar 的概念有疑问。
更多信息请参见 2.1.4。替代方案，4.6。替代方案和4.7。修复不满意和不明确的依赖项（但我猜这就是您正在阅读的内容）。
更新：回答您的其他问题。
这不可能发生，bean 存档必须有一个
bean.xml（可以是空的），详细信息请参阅15.6 节。文档的打包和部署：然后，要修复不满足且不明确的依赖关系，请参阅前面提到的 4.7 节。
更新2：使用
BeforeBeanDiscovery.addAnnotatedType()似乎可以添加在bean发现期间要考虑的其他类。 （BeforeBeanDiscovery是一个事件）My understanding of an alternative is that it's an alternative to some other implementation of an interface that you can use in a different deployment environment (e.g. a testing environment). An alternative bean is declared by annotating it with
@Alternative.To use an alternative in a given deployment scenario, you select it in the
<alternatives>element of your CDI deployment descriptorMETA-INF/beans.xml. This will enable@Alternativebeans which are disables by default.When enabled, if the container finds an ambiguous dependency for a given injection point, it will look at alternatives that could be injected and, if there is exactly one, pick up this alternative.
In other words, alternatives are a nice way to replace an existing implementation with another one at deployment time. If there is nothing to replace, you don't need alternatives, just put your jar on the class path. Not sure this was exactly your question though, I have a doubt about the concept of 3rd-party jars.
More in 2.1.4. Alternatives, 4.6. Alternatives and 4.7. Fixing unsatisfied and ambiguous dependencies (but I guess that this is what you're reading).
Update: To answer your additional question.
This can't happen, a bean archive must have a
bean.xml(be it empty) as detailed in the section 15.6. Packaging and deployment of the documentation:Then, to fix an unsatisfied and ambiguous dependency, refer to the section 4.7 previously mentioned.
Update 2: It appears that using
BeforeBeanDiscovery.addAnnotatedType()it is possible to add other classes to be taken into consideration during bean discovery. (BeforeBeanDiscoveryis an event)