It's possible the exception was swallowed somewhere and not logged
properly. But it's hard to know where from just looking at the code, is
it possible to share your test case for us to take a look from our side?
Thanks,
- Hong
On 4/19/2011 3:10 PM, forums_at_java.net wrote:
> 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
>
>