Question

目前，我们有一个精心设计的POJO对象结构，用于处理Web服务请求，称为“处理器”。

在提供此请求期间调用的远程和本地EJB和PersistenceContext在statless bean中初始化并传递给此处理器＆＃39;在每个Web服务请求期间重新创建的构造函数。

如果我不想在我的＆＃39;处理器内部恢复到JNDI查找。我继续通过我的代码拖动所有这些EJB。

输入CDI。我希望能够在这个＆＃39;处理器中随时注入这些EJB。

然而，我也注意到这意味着当前的处理器＆＃39;必须成为一个CDI bean：所以，使用实现webservice的无状态会话Bean中的@Inject。

当我这样做时，处理器的entiry生命周期将被绑定到bean而不是它所服务的请求。

突然之间，我必须考虑到我不应该在处理器中保留状态（注入的对象除外），因为这种状态将在多个webservice调用之间共享。作为一名程序员，这并没有让我的生活更轻松。

那么：我该怎么做呢？我已经了解了范围界定，但我不确定这是否会对我有所帮助。

示例，无状态bean：

@Stateless
@WebService
public class ExampleBean {

    @Inject
    Processor requestScopedInstance;

    int beanDependentScopeCounter;

    public String sayHello() {
        System.out.println( "bean object id: " + this.toString() );
        return requestScopedInstance.sayHello(beanDependentScopeCounter++);
    }
}

接口：

public interface Processor {

    String sayHello(int beanScopedCounter);
}

实现：

public class ProcessorImpl implements Processor {

    private int requestScopedCounter = 0;

    @Override
    public String sayHello(int beanScopedCounter) {
        return "test, requestScoped: " + requestScopedCounter++ + ", beansScoped: " + beanScopedCounter;
    }

}

Answer 1

When I do this the entiry lifecycle of the processor becomes bound to the bean and not to the request its serving这是不正确的。只有在您不使用@ApplicationScoped，@ SessionScoped，@ RequestScoped时才会出现这种情况。

所以：

使用@RequestScoped。
您不需要移交EJB，只需在必要时注入它们。
对使用注入对象的构造函数代码使用@PostConstruct带注释的方法。
无状态POJO可以注释@ApplicationScoped，而非无状态POJO可以保持默认的依赖范围。

这是可能的，因为代理是注入的，而不是实际的bean。使用这些代理CDI可确保为您的特定呼叫使用正确的范围。

CDI在无状态会话Bean请求中注入

1 个答案: