Still working on this. Sigh. There are no exceptions during deploy/startup
until:
[#|2011-04-19T11:01:45.261-0600|SEVERE|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=Thread-2;|Exception
while loading the app|#]
The next exceptions are things like:
Exception while shutting down application container :
java.lang.NullPointerException
[#|2011-04-19T11:09:47.948-0600|SEVERE|oracle-glassfish3.1|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=224;_ThreadName=Thread-2;|MDB00050:
Message-driven bean [RevEnterprise:ReportWatchMDB]: Exception in creating
message-driven ejb : [java.lang.NullPointerException]|#]
[#|2011-04-19T11:09:47.948-0600|SEVERE|oracle-glassfish3.1|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=224;_ThreadName=Thread-2;|java.lang.NullPointerException
java.lang.NullPointerException at
com.sun.ejb.containers.BaseContainer.injectEjbInstance(BaseContainer.java:1693)
at
com.sun.ejb.containers.MessageBeanContainer.createMessageDrivenEJB(MessageBeanContainer.java:707)
at
com.sun.ejb.containers.MessageBeanContainer.access$100(MessageBeanContainer.java:100)
at
com.sun.ejb.containers.MessageBeanContainer$MessageBeanContextFactory.create(MessageBeanContainer.java:484)
at
com.sun.ejb.containers.util.pool.NonBlockingPool.preload(NonBlockingPool.java:338)
at
com.sun.ejb.containers.util.pool.NonBlockingPool.doResize(NonBlockingPool.java:586)
at
com.sun.ejb.containers.util.pool.NonBlockingPool$IdleBeanWork.run(NonBlockingPool.java:684)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at
java.util.concurrent.FutureTask.run(FutureTask.java:138) at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662) |#]
which seem, like Marina said in another part of this thread, to indicate that
things have generally not gone well during the deployment. So I'm poking
around more in the source code, and the "Exception while loading the app"
with no message or stack trace seems to be logged by
com.sun.enterprise.v3.server.ApplicationLifecycle line 463.
// now were falling back into the mainstream loading/starting sequence, at
this // time the containers are set up, all the modules have been prepared in
their // associated engines and the application info is created and
registered if (loadOnCurrentInstance(context)) {
appInfo.setLibraries(commandParams.libraries()); try { appInfo.load(context,
tracker); appInfo.start(context, tracker); } catch(Throwable loadException) {
report.failure(logger, "Exception while loading the app", null);
report.setFailureCause(loadException); tracker.actOn(logger); return null; }
}
Since the ActionReport object is coming from a DeploymentContext across a few
layers, I'm not seeing what happens to it such that the stack trace might be
logged somewhere. Is it?
I'm pretty much out of ideas at this point. I need more information. My last
idea is to run the debugger on glassfish itself and put a breakpoint inside
that catch block so I can see where in the world the thing is dying. I'll be
working on that, unless someone has other ideas.
--
[Message sent by forum member 'culli']
View Post: http://forums.java.net/node/789009