1

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

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

2 回答 2

2

It is always a good idea not to create threads manually (ExecutorService seems fine in some cases though).

Actually MDBs are very often used to address this limitation: instead of creating a separate thread, send some task object (put something like MyJob extends Serializable in ObjectMessage) into the queue and let it be executed in MDB thread pool. This approach is much more heavyweight but scales very well and you don't have to manage any threads manually. In this scenario JMS is just a fancy way of running jobs asynchronously.

于 2011-04-17T10:19:21.407 回答
0

这些 EJB 限制通常不是硬限制。实际上，它们并不是关于使您的 EJB正常工作的警告，它们更像是关于如何使您的 EJB在 EJB 容器之间可移植的建议。

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

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

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

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

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

有趣的问题。

于 2011-04-18T19:11:52.593 回答