java - 桌面应用程序中的CDI

我正在创建可以由WEB或DESKTOP应用程序使用的JAR。这个JAR应该有一些带有@RequestScoped的类和其他CDI注释，因此我对此有一些疑问：

1）我知道@RequestScoped仅用于HTTP REQUEST，但是如何在桌面应用程序中使用它？这是可能的 ？
2）我正在使用此依赖项：

<dependency>
            <groupId>org.jboss.weld.servlet</groupId>
            <artifactId>weld-servlet</artifactId>
            <version>2.4.1.Final</version>
        </dependency>

但是这种依赖性仅适用于WEB焊接，我需要一些更通用的方法才能在WEB或DESKTOP中工作。

如果我使用“ weld-se”作为依赖项，那么我的JAR仅适用于桌面，我不想这样做。

最佳答案

就像用户MouseEvent在评论中所说的那样，通常最好有两个单独的JAR。

但是，我要回答的是您有关非Web环境中的@RequestScoped bean（以及@Session和@Application）的问题。假设我们在SE环境中使用Weld-现在，什么有效，什么无效？


@ApplicationScoped可以正常工作，并且符合您的期望。每个应用程序一个bean。它的生命周期在启动容器时开始，在关闭容器时停止。替代方法是使用@javax.inject.Singleton（注意，这是CDI singleton，而不是EJB）Bean，但应仅限于SE-这与应用程序范围的Bean行为相同，但未创建代理。在某些情况下，这可能会让您占上风，但也会阻止序列化之类的事情。
目前，@SessionScoped在SE环境中不起作用，因为它在那里实际上没有任何意义。正如您自己说的那样，您在那里没有会议。
@RequestScoped在SE中有效。这是有道理的，因为“请求”可能意味着比简单的旧HTTP请求更多的东西。但是，您将需要激活该范围。尽管有几种方法（例如扩展上下文和自己处理激活），但我建议使用Weld API-@ActivateRequestContext中提供的注释（实际上是拦截器绑定）。您只需将注释放在方法顶部，Weld将在方法启动之前激活请求上下文，然后将其关闭。您也可以将其放在整个类上，这意味着它将对每种方法都适用。请注意，您将需要依赖Weld API来访问此批注（或者您需要在此was added as well的位置使用CDI 2.0）。


至于您的依赖性，在SE环境中，您需要以下一种：

<dependency>
   <groupId>org.jboss.weld.se</groupId>
   <artifactId>weld-se</artifactId>
   <version>2.4.1.Final</version>
</dependency>

关于java - 桌面应用程序中的CDI，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/41709859/