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.
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.
--
[Message sent by forum member 'culli']
View Post: http://forums.java.net/node/789009