Have you ever seen exception like this in your glassfish server logs during ear deployment?
[#|2013-02-05T08:08:40.769+0100|SEVERE|glassfish3.1.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=90;_ThreadName=Thread-2;|Exception while shutting down application container|#] [#|2013-02-05T08:08:40.938+0100|SEVERE|glassfish3.1.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=90;_ThreadName=Thread-2;|Exception while shutting down application container : java.lang.NullPointerException|#]Well I did, today. And as I've googled, noone could ever get some more meaningfull stacktrace out of it. Sounds like a nightmare. So where the problem could be?
In development following rule usually works for me:
If you can't get any meaningful information on the problem you're facing and googling didn't help, think of what has been changed since the last success.
(Well this doesn't seem to be always applicable, but most of the time it is)
This rule was also worked for another guy facing similar exception.
Well in my case too many things changed, but I had backup of the last successfully built artifact. Comparing it with the latest one I've found out that I forgot to include commons-pool dependency in my ear file. So finally following did the trick for me:
<dependency> <groupId>commons-pool</groupId> <artifactId>commons-pool</artifactId> <version>1.6</version> <scope>runtime</scope> </dependency>As I introduced for client-server communication spring remoting (as a corba alternative) where pooling is used.
So hey, that wasn't so bad although exception handling of glassfish didn't show something useful! I tought I'll be stuck here for at least a day :)