Are Message-Driven Beans (MDB) bound to the same restrictions as other EJB beans?

Question

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

Answer 1

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.

Answer 2

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.