消息驱动 Bean (MDB) 是否与其他 EJB bean 受到相同的限制？

Question

在消息驱动的 Bean 中，我是否受限于会话 Bean（EJB3 或 EJB3.1）的相同规则，即：

• 使用 java.lang.reflect Java 反射 API 访问通过 Java 运行时环境的安全规则不可用的信息
• 读取或写入非最终静态字段
• 使用 this 来引用方法参数或结果中的实例
• 访问因 Java 编程语言规则而无法使用的包（和类）
• 在包中定义一个类
• 使用 java.awt 包创建用户界面
• 创建或修改类加载器和安全管理器
• 重定向输入、输出和错误流
• 获取代码源的安全策略信息
• 访问或修改安全配置对象
• 创建或管理线程
• 使用线程同步原语与其他企业 bean 实例同步访问
• 停止 Java 虚拟机
• 加载原生库
• 在网络套接字上侦听、接受连接或多播
• 更改 java.net.Socket 或 java.net.ServerSocket 中的套接字工厂，或更改 java.net.URL 的流处理程序工厂。
• 直接读取或写入文件描述符
• 在文件系统中创建、修改或删除文件
• 使用 Java 序列化协议的子类和对象替换特性

Answer 1

最好不要手动创建线程（ExecutorService 在某些情况下似乎很好）。

实际上，MDB 经常用于解决这个限制：与其创建单独的线程，不如将一些任务对象（在ObjectMessage 中放入类似MyJob extends Serializable 的东西）发送到队列中，让它在 MDB 线程池中执行。这种方法更重量级，但扩展性很好，您不必手动管理任何线程。在这种情况下，JMS 只是一种异步运行作业的奇特方式。

Answer 2

这些 EJB 限制通常不是硬性限制。事实上，它们并不是关于使您的 EJB 工作正确的警告，它们更像是关于如何使您的 EJB 可移植的建议em> 跨 EJB 容器。

有时，一些非常挑剔的 EJB 容器提供商（咳……WebSphere……咳）实际上会通过 java 安全策略强制执行这些限制，但我想说大约有一半的限制通常会被忽略（我意味着仅在您的 MDB 中使用 log4j 可能会违反其中的 30%）。

违反其他 70% 可能表明存在一些架构或设计问题。

那么，您可以在 MDB 中调用 System.exit() 吗？ answer 是肯定的，但只有一次...... :)

听起来，在您的情况下，您需要其中一些限制来控制可能行为不端的插件。我不知道 MDB 是否能让你摆脱这个问题。我想这取决于您对第三方开发人员的信任程度，但不是在 EJB 中使用基于调用的模型，而是将组件安装为 JMX ModelMBeans。您可以使用 java 安全模型来限制他们可以做的事情，但我想这会破坏目的。

也许使用一些运行（或加载）时间 AOP 字节码工程，您可以重写所有线程请求，以将其重定向到您分配的每个组件线程工厂，并限制可以创建的线程。因为您不想阻止他们做他们所做的任何事情，所以您只是不希望他们在崩溃/停止/行为不端时关闭整个服务器。

有趣的问题。