消息驱动 Bean (MDB) 是否与其他 EJB Bean 一样受到相同的限制？
在消息驱动 Bean 中，我受限于会话 Bean（EJB3 或 EJB3.1）的相同规则，即：
- 使用 java.lang.reflect Java Reflection API 来访问通过 Java 运行时的安全规则不可用的信息环境
- 读取或写入非最终静态字段
- 使用此引用方法参数或结果访问包（和类）中的实例
- ，否则这些包（和类）根据 Java 编程语言的规则不可用
- 在包中定义类
- 使用 java.awt 包到创建用户界面
- 创建或修改类加载器和安全管理器
- 重定向输入、输出和错误流
- 获取代码源的安全策略信息
- 访问或修改安全配置对象
- 创建或管理线程
- 使用线程同步原语要与其他企业 bean 实例同步访问，
- 请停止 Java 虚拟机，
- 加载本机库，
- 侦听、接受来自网络套接字的连接或多播，
- 更改 java.net.Socket 或 java.net.ServerSocket 中的套接字工厂，或者更改流java.net.URL 的处理程序工厂。
- 直接读取或写入文件描述符
- 在文件系统中创建、修改或删除文件
- 使用 Java 序列化协议的子类和对象替换功能
In a Message-Driven Bean am I restricted to the same rules of Session Beans (EJB3 or EJB3.1), i.e:
- use the java.lang.reflect Java Reflection API to access information unavailable by way of the security rules of the Java runtime environment
- read or write nonfinal static fields
- use this to refer to the instance in a method parameter or result
- access packages (and classes) that are otherwise made unavailable by the rules of Java programming language
- define a class in a package
- use the java.awt package to create a user interface
- create or modify class loaders and security managers
- redirect input, output, and error streams
- obtain security policy information for a code source
- access or modify the security configuration objects
- create or manage threads
- use thread synchronization primitives to synchronize access with other enterprise bean instances
- stop the Java virtual machine
- load a native library
- listen on, accept connections on, or multicast from a network socket
- change socket factories in java.net.Socket or java.net.ServerSocket, or change the stream handler factory of java.net.URL.
- directly read or write a file descriptor
- create, modify, or delete files in the filesystem
- use the subclass and object substitution features of the Java serialization protocol
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不要手动创建线程总是一个好主意（ExecutorService 在某些情况下似乎很好）。
实际上，MDB 通常用于解决此限制：不是创建单独的线程，而是发送一些任务对象（将诸如
MyJob extends Serialized之类的内容放入ObjectMessage中）放入队列中，然后让它在MDB线程池中执行。这种方法更加重量级，但扩展性非常好，并且您不必手动管理任何线程。在这种情况下，JMS 只是一种异步运行作业的奇特方式。It is always a good idea not to create threads manually (
ExecutorServiceseems 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 SerializableinObjectMessage) 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.这些 EJB 限制通常不是硬限制。事实上，它们并不是让您的 EJB正常工作的警告，它们更像是关于如何使您的 EJB可移植的建议。 em> 跨 EJB 容器。
有时，一些非常挑剔的 EJB 容器提供商（咳……WebSphere……咳）实际上会通过 java 安全策略强制执行这些限制，但我想说，其中大约一半的限制通常会被忽略（我的意思是仅使用MDB 中的 log4j 可能违反了其中约 30% 的规则）。
违反其他 70% 可能表明存在一些架构或设计问题。
那么，您可以在 MDB 中调用 System.exit() 吗？ 答案是肯定的，但只有一次。 .. :)
听起来，就您的情况而言，您需要其中一些限制来控制潜在的行为不当的插件。我不知道 MDB 是否能让你摆脱这个问题。我想这取决于您对第三方开发人员的信任程度，但我不会在 EJB 中使用基于调用的模型，而是将组件安装为 JMX ModelMBean。您可以使用 java 安全模型来限制它们可以执行的操作，但我认为这会达不到目的。
也许使用一些运行（或加载）时 AOP 字节代码工程，您可以重写所有线程请求，将其重定向到您分配的每个组件线程工厂，并限制可以创建的线程。因为您不想阻止他们做他们所做的任何事情，所以您只是不希望他们在崩溃/停滞/行为不当时关闭整个服务器。
有趣的问题。
These EJB restrictions are typically not hard restrictions. In fact, they're not caveats on making your EJBs work properly, they're more like advisories on how to make your EJBs portable across EJB containers.
From time to time, some very fussy EJB container providers (cough.... WebSphere... cough) will actually enforce these restrictions through java security policies, but I would say about half of those restrictions are routinely ignored ( I mean just using log4j in your MDB potentially violates about 30% of them).
Violating the the other 70% probably indicates some architectural or design problem.
So, can you call System.exit() in an MDB ? The answer is yes, but only once... :)
It sounds like, in your case, you need some of these restrictions to reign in potentially misbehaving plugins. I don't know if MDBs are going to get you out of that problem. I suppose it depends on how much you trust the third party developers, but rather than use the invocation based models in EJB, I would install the components as JMX ModelMBeans. You can use the java security model to limit what they can do, but I suppose that would defeat the purpose.
Perhaps using some run (or load) time AOP byte code engineering, you could rewrite all requests for threads to be redirected to a per component thread factory that you allocate and limits the threads that can be created. Because you don't want to stop them from doing whatever it is that they do, you just don't want them to take down the whole server when they crash/stall/misbehave.
Interesting problem.