Use @Singleton, not @Stateless

Something I’ve been musing over in the background for some time. This is not revolutionary.

In almost any circumstance that I can think of, you probably want to be using @Singleton EJBs, not @Stateless EJBs.

In this day and age with these JVMs and these JITs, the object pooling mechanisms which seemed so necessary back in the EJB 1.x days seem laughable now.

In addition, if you’re careful, you can use concurrent utilities in your @Singleton as well, whereas the specification prevents you from doing so in any other bean type.

Inconsistent Module State

Another note for posterity.

GlassFish has trouble gracefully recovering from attempting to deploy applications that are badly formed.

Sometimes you get this error:

[#|2013-09-04T12:11:32.903-0400|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=21;_ThreadName=Thread-2;|Exception while loading the app : Error in linking security policy for yourapp -- Inconsistent Module State|#]

This results from GlassFish happily plowing along and generating a security policy in your domain’s generated directory, and then encountering an error, and not cleaning up the partially generated security policy file. That file sticks around for the next deployment, and until you blow it away you will find no peace.

A StackOverflow article covers it, but apparently believes that it is magic. No amount of restarting or otherwise chanting spells over your GlassFish will fix the problem; you have to delete the contents of your domain’s generated directory.