Skip to main content

Problems converting app from 2.1 to 3.1

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
12 replies [Last post]
culli
Offline
Joined: 2006-09-17

I have an app that runs fine with JEE 5 and Glassfish 2.1.1. Now I'm trying to upgrade to JEE 6 and Glassfish 3.1, but there are problems. On deployment I get the error "Exception while loading the app". How do I get more information? The log isn't being very helpful here. I've dialed all the levels up to FINE and it's not helping. Later on the log says "RAR8505: Application [ MyApp ] does not seem to have started. Skipping Inbound Recovery for the application."
I feel fairly experienced in finding the source of the problem with Glassfish 2.1, but I'm missing something here. To quote XKCD "my normal approach is useless here". If the log levels are at INFO and the error "Exception while loading the app" is reported, shouldn't there be something--anything--to explain that? Then upping the log levels should help, but no luck.
Suggestions?
I'm going to start building up a simple app and adding parts of my app to see if I can deploy anything at all. I really just doing that for something to try. The glassfish install is just the ogs zip file unzipped, using the domain it comes with.
The error and useless (to me) stack trace:

[#|2011-04-05T10:48:08.590-0600|SEVERE|oracle-glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=1;_ThreadName=Thread-2;|Exception while loading the app|#]

[#|2011-04-05T10:48:08.597-0600|WARNING|oracle-glassfish3.1|javax.enterprise.system.core.classloading.com.sun.enterprise.loader|_ThreadID=1;_ThreadName=Thread-2;|Input stream has been finalized or forced closed without being explicitly closed; stream instantiation reported in following stack trace

java.lang.Throwable

        at com.sun.enterprise.loader.ASURLClassLoader$SentinelInputStream.<init>(ASURLClassLoader.java:1230)
        at com.sun.enterprise.loader.ASURLClassLoader$InternalJarURLConnection.getInputStream(ASURLClassLoader.java:1338)
        at java.net.URL.openStream(URL.java:1010)
        at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration$1.run(VersionHelper12.java:199)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration.getNextElement(VersionHelper12.java:194)
        at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration.hasMore(VersionHelper12.java:214)
        at com.sun.naming.internal.ResourceManager.getApplicationResources(ResourceManager.java:470)
        at com.sun.naming.internal.ResourceManager.getInitialEnvironment(ResourceManager.java:159)
        at javax.naming.InitialContext.init(InitialContext.java:219)
        at javax.naming.InitialContext.<init>(InitialContext.java:197)
        at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.initializeRemoteNamingSupport(GlassfishNamingManagerImpl.java:157)
        at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:139)
        at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getProtocolManager(GlassFishORBHelper.java:187)
        at com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:818)
        at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:566)
        at com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:155)
        at com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:149)
        at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:105)
        at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234)
        at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:290)
        at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:101)
        at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
        at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:249)
        at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
        at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:364)
        at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:208)
        at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
        at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
        at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
        at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
        at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
        at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
        at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:243)
        at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
        at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
        at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
        at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
|#]

Possibly irrelevant, but at one point I was getting "Request URI is too large", but I changed the URI max to 0, just to get past that for now.
[#|2011-04-05T10:37:28.741-0600|SEVERE|oracle-glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=20;_ThreadName=Thread-2;|GRIZZLY0039: Request URI is too large.

java.nio.BufferOverflowException
        at com.sun.grizzly.tcp.http11.InternalInputBuffer.fill(InternalInputBuffer.java:765)
        at com.sun.grizzly.tcp.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:467)
        at com.sun.grizzly.http.ProcessorTask.parseRequest(ProcessorTask.java:855)
        at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:692)
        at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
        at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
        at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
        at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
        at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
        at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
        at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
        at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
culli
Offline
Joined: 2006-09-17

Thanks to everyone who commented on this thread, and sorry it took so long, but the good news is that I got the app to deploy!

The final hurdle was getting things arranged with the jersey jars. The app was still using Jersey 1.0.3 and I couldn't see a good way to get the bundled Jersey 1.5 to downgrade, so I upgraded our code. This took some research, but ended up being not that hard. One fun error was "com.sun.jersey.spi.inject.Errors|The following errors and warnings have been detected with resource and/or provider classes: SEVERE: Missing dependency for constructor public com.blah.Foo(java.lang.String) at parameter index 0. Turns out that Foo had a constructor on it (your guess is as good as mine as to why) with a parameter, but a root resource in Jersey needs a no-args constructor."

I wasn't meticulous with writing down the changes I have made to the .ear file along the way, but I think I document most of the trickiest spots.
But again, it works!

culli
Offline
Joined: 2006-09-17

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.

hzhang_jn
Offline
Joined: 2005-07-22

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@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
>
>

culli
Offline
Joined: 2006-09-17

I can't easily give you this ear file, because there is quite a bit of configuration with jdbc and jms datasources and getting permission from legal would be difficult. Anyway, I was able to build glassfish with some added logging and below is the error I'm getting. It looks like this error: http://forums.java.net/node/701804?force=407 and this: http://java.net/jira/browse/GLASSFISH-13772

I am now hunting for EJB's in my library jars. I'll post back if I find one, and if it worked yet.

[#|2011-04-26T13:12:42.094-0600|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=1;_ThreadName=Thread-1;|org.glassfish.deployment.common.DeploymentException: Error in linking security policy for RevEnterprise -- Inconsistent Module State
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.enterprise.security.SecurityUtil.linkPolicyFile(SecurityUtil.java:335)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.enterprise.security.SecurityDeployer.linkPolicies(SecurityDeployer.java:271)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.enterprise.security.SecurityDeployer.access$100(SecurityDeployer.java:81)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.enterprise.security.SecurityDeployer$AppDeployEventListener.event(SecurityDeployer.java:114)
<span class="Apple-tab-span" style="white-space:pre"> </span>at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
<span class="Apple-tab-span" style="white-space:pre"> </span>at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:262)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:364)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:208)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:243)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
<span class="Apple-tab-span" style="white-space:pre"> </span>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

<span class="Apple-tab-span" style="white-space:pre"> </span>at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
<span class="Apple-tab-span" style="white-space:pre"> </span>at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
<span class="Apple-tab-span" style="white-space:pre"> </span>at java.lang.reflect.Method.invoke(Method.java:597)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
<span class="Apple-tab-span" style="white-space:pre"> </span>at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
|#]

I propose this patch to make this easier to diagnose. In core/kernel/src/main/java/com/sun/enterprise/v3/server/ApplicationLifecycle.java (line 457 in tags/3.1-b43):

if (loadOnCurrentInstance(context)) {
    appInfo.setLibraries(commandParams.libraries());
    try {
        appInfo.load(context, tracker);
        appInfo.start(context, tracker);
    } catch(Throwable loadException) {
        report.failure(logger, &quot;Exception while loading the app&quot;, loadException);  //*****loadException instead of null, why null?  if that's what was intended, there should be a comment.
        report.setFailureCause(loadException);
        tracker.actOn(logger);
        return null;
    }
}
tjquinn
Offline
Joined: 2005-03-30

Yes, the error can indeed be mystifying.
Briefly, GlassFish detected that a stream to an application file was opened but never explicitly closed. The stack trace shows where the stream was opened as a hint about what part of the code might need to close it too.
This message is a warning, but for some reason the load operation failed. (It looks as if a previously-deployed app is being reloaded during server start-up. Is that right?) The two messages are very close in time (.007 s apart) so it looks as if the warning caused load to fail, which it should not.
Does this happen on every restart with this app deployed? Were there other errors in the log file just before or just after this one? (I know you mentioned the URI length problem which you resolved.)
- Tim

culli
Offline
Joined: 2006-09-17

Thanks for looking into this. You are right, this particular log entry was during a restart. I have tried deploying the app to the admin instance to rule out some kind of misconfiguration with the cluster I'm setting up. It's just a single node on the same machine for the moment. Both the admin and cluster instance behave the same way.

My current theory is that it's an ejb timer causing problems during application startup. The app has a web app that initializes the timer on startup in a way that ensures only one of the instances in the cluster will be running the timer. This was necessary in 2.1, but maybe it's not in 3.1. Tomorrow when I'm back at work I'm going to start from scratch, adding pieces of the app in one at a time and see if I can make any headway on this.

When the log levels are at INFO there are no other errors. Pushing them up to FINE it comes up with a bunch of stuff that really seems unrelated.

And yes, this happens on every restart.

Jim

mvatkina
Offline
Joined: 2005-04-04

Jim,
Do you use postgresql by any chance? There was a report that some version of a driver causes problems accessing JPA (and EJB timer service uses JPA in the background) in the servlet init() method.

-marina

culli
Offline
Joined: 2006-09-17

We use MySQL, but that is a good point. I will check the driver version we are using.

culli
Offline
Joined: 2006-09-17

So I'm making progress on this slowly, as I have time. I've fixed a few little things, and come to really hate a bug where it doesn't show a jms error message due some resource bundle lookup problem. I can't find the bug number again, but it was already reported, and I think was still unresolved. The jms queue for an mdb was missing, but it took forever to figure that out due to the resource bundle bug. [EDIT: this one http://java.net/jira/browse/GLASSFISH-15981]

One problem seems to have been that some of our code looked up @Local interfaces using the jndi from @Stateless(mappedName="") which worked in GF 2.1, but not in 3.1. I understand why it does not and should not work that way, and now all these @Local interface lookups are @EJB injections.

Another problem was that the version of SLF4J we were including in our ear was somehow incompatible with the one bundled in one or more of the osgi modules. I'm not completely sure of this, but it looks like 1.5.8 works, but other versions don't. Some classloader problem like classdefnotfound LoggerFactory. Didn't write that down exactly, and the log is gone.

The current problem I need help with is this error during startup. The MDB referenced by the error has a Remote interface injected with @EJB. What's going on here?

[#|2011-04-14T15:40:30.137-0600|SEVERE|oracle-glassfish3.1|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=253;_ThreadName=Thread-2;|MDB0

0050: Message-driven bean [RevEnterprise:ReportWatchMDB]: Exception in creating message-driven ejb : [java.lang.NullPointerException]|#]



[#|2011-04-14T15:40:30.138-0600|SEVERE|oracle-glassfish3.1|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=253;_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)

|#]

I cannot deploy directly because of this error, deploying from the gui. The das thinks it deployed ok, but the instance/node log has this error:
[#|2011-04-14T16:26:56.550-0600|SEVERE|oracle-glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=77;_ThreadName=Thread-2;|GRIZZLY0039: Request URI is too large.

java.nio.BufferOverflowException

        at com.sun.grizzly.tcp.http11.InternalInputBuffer.fill(InternalInputBuffer.java:765)

        at com.sun.grizzly.tcp.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:467)

        at com.sun.grizzly.http.ProcessorTask.parseRequest(ProcessorTask.java:855)

        at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:692)

        at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)

        at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)

        at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)

        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)

        at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)

        at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)

        at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)

        at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)

        at com.sun.grizzly.ContextTask.run(ContextTask.java:71)

        at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)

        at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)

        at java.lang.Thread.run(Thread.java:662)

|#]

I took a look at the BaseContainer source code, but I don't really have the ability to digest that quickly enough. There is so much context I don't understand. As a guess it looks like a creation order problem, referencing an object that doesn't get created until the app is started up all the way.

mvatkina
Offline
Joined: 2005-04-04

Something went completely wrong for you to get that NPE - it means the InterceptorManager is null, and it is constructed via 'new InterceptorManager()' at the bean container startup... So look for any exceptions much earlier that the NPE.

-marina

mvatkina
Offline
Joined: 2005-04-04

Persistent EJB timer always runs/expires on only one instance in a cluster. Are you trying to recreate timers on instance startup?

-marina

culli
Offline
Joined: 2006-09-17

Yes, we try to create the timers on startup. This is done in a startup servlet which looks for a timer with the name we want and if it's not there, it is created. This was the only way in 2.1 that I could find that would create the timer only once in the cluster. EJB 3.1 may provide a better way, I haven't researched it yet.

Anyway my point was to rule out the timers as the source of my deployment problems, so this code is temporarily disabled.