Java 不带范围的bean的CDI注入

Java 不带范围的bean的CDI注入,java,cdi,Java,Cdi,我们有一个CDI项目,使用: 托米容器 ApacheOpenWebbeansforCDI Deltaspike CDI扩展 在webapp的beans.xml文件中,发现模式被配置为建议的设置:bean discovery mode=“annotated”。尽管如此,我还是能够注入这个类,它没有使用作用域进行注释: public class TestClass implements Serializable { public String getDescription() {

我们有一个CDI项目,使用:

  • 托米容器
  • ApacheOpenWebbeansforCDI
  • Deltaspike CDI扩展
在webapp的
beans.xml
文件中,发现模式被配置为建议的设置:
bean discovery mode=“annotated”
。尽管如此,我还是能够注入这个类,它没有使用作用域进行注释:

public class TestClass implements Serializable {
    public String getDescription() {
        return "This is a test class";
    }
}
进入这个
ViewScoped
类,没有任何问题:

@ViewScoped
@Named
public class AuthenticationWebBean implements Serializable {

    @Inject
    private TestClass testClass;
我希望它要么抛出异常,要么将字段保留为null。这里发生了什么,注入的
对象
会与它注入的
对象
具有相同的作用域吗


提前感谢。

TomEE通常只支持JavaEE6,只有night builds支持JavaEE7<代码>bean发现模式=“annotated”仅在JavaEE7中受支持。这意味着在TomEE中,它很可能被忽略,然后所有的豆子都被认为是注射用的。如果要从注入中排除bean,请使用
@Alternative
对其进行注释。否则,bean将被注入与其被注入的bean相同的作用域。这相当于默认的
@Dependent
作用域。

TomEE通常只支持javaee6,只有夜间构建支持javaee7<代码>bean发现模式=“annotated”仅在JavaEE7中受支持。这意味着在TomEE中,它很可能被忽略,然后所有的豆子都被认为是注射用的。如果要从注入中排除bean,请使用
@Alternative
对其进行注释。否则,bean将被注入与其被注入的bean相同的作用域。这相当于默认的
@Dependent
作用域。

您描述的行为在CDI 1.1/1.2中,Java EE 7兼容容器将遵循它

您正在使用符合JavaEE6/CDI1.0的Tomee1.7.2。它将在CDI1.0的规则下运行,这使得一切都成为CDI组件


TomEE 7将开始演示您所描述的行为。

您所描述的行为在CDI 1.1/1.2中,Java EE 7兼容容器将遵循它

您正在使用符合JavaEE6/CDI1.0的Tomee1.7.2。它将在CDI1.0的规则下运行,这使得一切都成为CDI组件


TomEE 7将开始演示您所描述的行为。

TestClass使用默认的CDI作用域,该作用域是
@Dependent
,每次请求时都会创建它(它不一定只是HTTP请求)。在注入点注入代理,每个请求的注入点可能是不同的实例。(注入点处的
TestClass
实例可能与创建时不同,因为注入的实例不是真实的实例-它是一个称为代理的假实例)。功能要求是什么?啊,这很有道理,谢谢你提供的信息。我问这个问题的原因是,当javax.faces库包含在webapp库中而不是Tomee库中时,我们看到了一个巨大的内存泄漏,请求的每个页面都会导致在WebContext中创建大量faces对象,并且从未发布。我怀疑这是我上面提到的行为的副作用,现在我知道@Dependent scope是有意义的!移动faces库解决了内存泄漏问题。您可以在bean上使用裸
javax.enterprise.inject.Typed
注释来防止它注册为CDI管理的bean。“指定注释时,只有使用
成员显式列出其类的类型以及
对象
才是bean的bean类型。”感谢您的帮助@Tiny为什么您认为TestClass获得了依赖范围?Bean发现模式被设置为“注释”,所以这个Bean根本不应该出现“未满足的依赖项”错误消息。它没有按预期的那样工作。
TestClass
使用默认的CDI作用域,该作用域是
@Dependent
,每次请求时都会创建它(它不一定只是HTTP请求)。在注入点注入代理,每个请求的注入点可能是不同的实例。(注入点处的
TestClass
实例可能与创建时不同,因为注入的实例不是真实的实例-它是一个称为代理的假实例)。功能要求是什么?啊,这很有道理,谢谢你提供的信息。我问这个问题的原因是,当javax.faces库包含在webapp库中而不是Tomee库中时,我们看到了一个巨大的内存泄漏,请求的每个页面都会导致在WebContext中创建大量faces对象,并且从未发布。我怀疑这是我上面提到的行为的副作用,现在我知道@Dependent scope是有意义的!移动faces库解决了内存泄漏问题。您可以在bean上使用裸
javax.enterprise.inject.Typed
注释来防止它注册为CDI管理的bean。“指定注释时,只有使用
成员显式列出其类的类型以及
对象
才是bean的bean类型。”感谢您的帮助@Tiny为什么您认为TestClass获得了依赖范围?Bean发现模式被设置为“注释”,所以这个Bean根本不应该出现“未满足的依赖项”错误消息。它并没有像它应该做的那样工作。但是《第七部大黄蜂》会被发行吗?或者它会像Geronimo那样停止,尽管他们从未说过他们停止了?它正在积极开发中。请随意浏览邮件列表,打声招呼。@john.ament如果团队对此能多沟通一点,那就太酷了。一段时间前,他们说2015年初在受到一点推动后,这已经是一个很好的结果