Difference between server restart and application restart

[chander_bawa]

Hi,
I have deployed an ear application on geronimo server and am facing a strange issue. After starting the server, i deploy the ear and it works perfectly. Its  a messaging application with  oracle queues integrated with JMS broker using Gbeans and listener classes.

When the server is restarted, the application gets deployed but it is not able to establish connection with the oracle queue which it could do so when the application was deployed for the first time.

The error that i get is -
java.lang.NullPointerException: You have accessed the java:comp jndi context on a thread that has not initialized it

Strangely, when i restart the application from admin console, everything works!

I want to know what is the difference in container's behaviour when server is restarted and when an application is restarted. It will be great if you find a flaw in code written or in case you anticipate one, please do let me know.
Expecting a prompt response...


Following is the piece of code which fails when the server is started again -

i_recvrQueueConn = oracle.jms.AQjmsQueueConnectionFactory.createQueueConnection( i_dbConnection );
i_recvrQueueConn.start();
i_recvrQueueSession = i_recvrQueueConn.createSession(false, Session.AUTO_ACKNOWLEDGE);

In the createSession statement, i get the following error -

java.lang.NullPointerException: You have accessed the java:comp jndi context on a thread that has not initialized it
        at org.apache.geronimo.gjndi.JavaCompContextGBean.getContext(JavaCompContextGBean.java:34)
        at org.apache.xbean.naming.context.ContextFlyweight.lookup(ContextFlyweight.java:47)
        at org.apache.xbean.naming.context.ContextFederation.getFederatedBinding(ContextFederation.java:69)
        at org.apache.xbean.naming.context.AbstractFederatedContext.getBinding(AbstractFederatedContext.java:63)
        at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:139)
        at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:625)
        at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:162)
        at org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611)
        at javax.naming.InitialContext.lookup(InitialContext.java:392)
        at oracle.jms.EmulatedXAHandler.<init>(EmulatedXAHandler.java:69)
        at oracle.jms.AQjmsSession.<init>(AQjmsSession.java:378)
        at oracle.jms.AQjmsConnection.createSession(AQjmsConnection.java:1132)
        at ltc.vise.hl7.gbean.OracleAQListener.<init>(OracleAQListener.java:101)
        at ltc.vise.hl7.gbean.OracleAQProxy.doStart(OracleAQProxy.java:103)
        at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:998)
        at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
        at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
        at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
        at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555)
        at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
        at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456)
        at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188)
        at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:563)
        at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
        at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
        at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832)
        at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
        at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
        at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
        at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$36339902.startConfiguration(<generated>)
        at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:162)
        at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
        at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
        at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
        at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)



Thanks,
Chander

[djencks]

Hi Chandler,

The mystery is not why this fails when the server is restarted but  
rather why it works when deployed from the console :-)

GBeans are not javaee components and so they don't have java:comp jndi  
contexts available to them.  If you do something with a gbean such as  
starting it from a javaee app such as the console, the gbean will see  
the java:comp context of the calling app, not the java:comp context of  
the (possibly javaee) app in which the gbean is deployed.

Do you have control over what oracle is trying to look up in jndi?

Ideally Oracle should supply a j2ca resource adapter for their  
messaging stuff.  Do you know what they actually do supply?  jms?  Do  
you need to use mdbs or just "plain" jms connections?  I think I  
recall comments in the activemq j2ca adapter that it was pretty much  
jms implementation neutral, you might be able to modify it to wrap the  
oracle jms implementation without much work.

thanks
david jencks

On Jun 25, 2009, at 2:44 AM, chander_bawa wrote:

>
> Hi,
> I have deployed an ear application on geronimo server and am facing a
> strange issue. After starting the server, i deploy the ear and it  
> works
> perfectly. Its  a messaging application with  oracle queues  
> integrated with
> JMS broker using Gbeans and listener classes.
>
> When the server is restarted, the application gets deployed but it  
> is not
> able to establish connection with the oracle queue which it could do  
> so when
> the application was deployed for the first time.
>
> The error that i get is -
> java.lang.NullPointerException: You have accessed the java:comp jndi  
> context
> on a thread that has not initialized it
>
> Strangely, when i restart the application from admin console,  
> everything
> works!
>
> I want to know what is the difference in container's behaviour when  
> server
> is restarted and when an application is restarted. It will be great  
> if you
> find a flaw in code written or in case you anticipate one, please do  
> let me
> know.
> Expecting a prompt response...
>
>
> Following is the piece of code which fails when the server is  
> started again
> -
>
> i_recvrQueueConn =
> oracle
> .jms.AQjmsQueueConnectionFactory.createQueueConnection( i_dbConnection
> );
> i_recvrQueueConn.start();
> i_recvrQueueSession = i_recvrQueueConn.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
>
> In the createSession statement, i get the following error -
>
> java.lang.NullPointerException: You have accessed the java:comp jndi  
> context
> on a thread that has not initialized it
> at
> org
> .apache
> .geronimo
> .gjndi.JavaCompContextGBean.getContext(JavaCompContextGBean.java:34)
> at
> org
> .apache
> .xbean.naming.context.ContextFlyweight.lookup(ContextFlyweight.java:
> 47)
> at
> org
> .apache
> .xbean
> .naming
> .context
> .ContextFederation.getFederatedBinding(ContextFederation.java:69)
> at
> org
> .apache
> .xbean
> .naming
> .context
> .AbstractFederatedContext.getBinding(AbstractFederatedContext.java:63)
> at
> org
> .apache
> .xbean.naming.context.AbstractContext.lookup(AbstractContext.java:139)
> at
> org
> .apache
> .xbean.naming.context.AbstractContext.lookup(AbstractContext.java:625)
> at
> org
> .apache
> .xbean.naming.context.AbstractContext.lookup(AbstractContext.java:162)
> at
> org
> .apache
> .xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611)
> at javax.naming.InitialContext.lookup(InitialContext.java:392)
> at oracle.jms.EmulatedXAHandler.<init>(EmulatedXAHandler.java:69)
> at oracle.jms.AQjmsSession.<init>(AQjmsSession.java:378)
> at oracle.jms.AQjmsConnection.createSession(AQjmsConnection.java:
> 1132)
> at ltc.vise.hl7.gbean.OracleAQListener.<init>(OracleAQListener.java:
> 101)
> at ltc.vise.hl7.gbean.OracleAQProxy.doStart(OracleAQProxy.java:103)
> at
> org
> .apache
> .geronimo
> .gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:998)
> at
> org
> .apache
> .geronimo
> .gbean
> .runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:
> 268)
> at
> org
> .apache
> .geronimo
> .gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at
> org
> .apache
> .geronimo
> .gbean
> .runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:
> 124)
> at
> org
> .apache
> .geronimo
> .gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555)
> at
> org
> .apache
> .geronimo
> .kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
> at
> org
> .apache
> .geronimo
> .kernel
> .config
> .ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:
> 456)
> at
> org
> .apache
> .geronimo
> .kernel
> .config
> .KernelConfigurationManager.start(KernelConfigurationManager.java:188)
> at
> org
> .apache
> .geronimo
> .kernel
> .config
> .SimpleConfigurationManager
> .startConfiguration(SimpleConfigurationManager.java:563)
> at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
> at
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org
> .apache
> .geronimo
> .gbean
> .runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:
> 34)
> at
> org
> .apache
> .geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
> at
> org
> .apache
> .geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832)
> at  
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:
> 57)
> at
> org
> .apache
> .geronimo
> .kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
> at
> org
> .apache
> .geronimo
> .kernel
> .basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:
> 96)
> at
> org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$
> $36339902.startConfiguration(<generated>)
> at
> org
> .apache
> .geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:
> 162)
> at
> org
> .apache
> .geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
> at
> org
> .apache
> .geronimo
> .kernel
> .util
> .MainConfigurationBootstrapper
> .main(MainConfigurationBootstrapper.java:45)
> at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:
> 67)
> at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
>
>
>
> Thanks,
> Chander
> --
> View this message in context: http://www.nabble.com/Difference-between-server-restart-and-application-restart-tp24200158s134p24200158.html
> Sent from the Apache Geronimo - Users mailing list archive at  
> Nabble.com.
>

[chander_bawa]

Thanks Djencks,
You are right. I tried deploying the ear from command line and faced the same issue.
The thing is i am working on upgrading the geronimo server from 1.1.1 to 2.1.4 and the application is working perfectly in 1.1.1
My confusion is why this error came when app is deployed on 2.1.4 when it worked perfectly on 1.1.1?

Chander

[djencks]

On Jun 26, 2009, at 12:02 AM, chander_bawa wrote:

>
> Thanks Djencks,
> You are right. I tried deploying the ear from command line and faced  
> the
> same issue.
> The thing is i am working on upgrading the geronimo server from  
> 1.1.1 to
> 2.1.4 and the application is working perfectly in 1.1.1
> My confusion is why this error came when app is deployed on 2.1.4  
> when it
> worked perfectly on 1.1.1?

The only reason I can think that this might work on 1.1.1 is that we  
had a bug in the jndi implementation in 1.1.1 that lets the lookup  
succeed.  It should fail on 1.1.1 just as it does on 2.1.4.

If you answer the questions I asked in my previous reply I might be  
able to suggest a way to proceed.  For instance you might be able to  
look the destinations up in the jca:/ global jndi context.

thanks
david jencks

>
> Chander
> --
> View this message in context: http://www.nabble.com/Difference-between-server-restart-and-application-restart-tp24200158s134p24215874.html
> Sent from the Apache Geronimo - Users mailing list archive at  
> Nabble.com.
>

[kevan]

On Jun 26, 2009, at 3:26 AM, David Jencks wrote:

>
> On Jun 26, 2009, at 12:02 AM, chander_bawa wrote:
>
>>
>> Thanks Djencks,
>> You are right. I tried deploying the ear from command line and  
>> faced the
>> same issue.
>> The thing is i am working on upgrading the geronimo server from  
>> 1.1.1 to
>> 2.1.4 and the application is working perfectly in 1.1.1
>> My confusion is why this error came when app is deployed on 2.1.4  
>> when it
>> worked perfectly on 1.1.1?
>
> The only reason I can think that this might work on 1.1.1 is that we  
> had a bug in the jndi implementation in 1.1.1 that lets the lookup  
> succeed.  It should fail on 1.1.1 just as it does on 2.1.4.
>
> If you answer the questions I asked in my previous reply I might be  
> able to suggest a way to proceed.  For instance you might be able to  
> look the destinations up in the jca:/ global jndi context.

I don't think they're looking for destinations. Instead, it's looking  
for a TransactionManager. This same problem was reported back in  
April. That user reported that the oracle adapter was looking for  
"java:comp/pm/TransactionManager". I wonder if they could be  
configured to look for "java:/TransactionManager".

I'm also wondering if throwing a RunTime exception is the appropriate  
behavior, in this situation. Why not a NamingException? I confess that  
the subtleties of JNDI are frequently lost on me...

--kevan

[djencks]

On Jun 26, 2009, at 6:11 AM, Kevan Miller wrote:

>
> On Jun 26, 2009, at 3:26 AM, David Jencks wrote:
>
>>
>> On Jun 26, 2009, at 12:02 AM, chander_bawa wrote:
>>
>>>
>>> Thanks Djencks,
>>> You are right. I tried deploying the ear from command line and  
>>> faced the
>>> same issue.
>>> The thing is i am working on upgrading the geronimo server from  
>>> 1.1.1 to
>>> 2.1.4 and the application is working perfectly in 1.1.1
>>> My confusion is why this error came when app is deployed on 2.1.4  
>>> when it
>>> worked perfectly on 1.1.1?
>>
>> The only reason I can think that this might work on 1.1.1 is that  
>> we had a bug in the jndi implementation in 1.1.1 that lets the  
>> lookup succeed.  It should fail on 1.1.1 just as it does on 2.1.4.
>>
>> If you answer the questions I asked in my previous reply I might be  
>> able to suggest a way to proceed.  For instance you might be able  
>> to look the destinations up in the jca:/ global jndi context.
>
> I don't think they're looking for destinations. Instead, it's  
> looking for a TransactionManager. This same problem was reported  
> back in April. That user reported that the oracle adapter was  
> looking for "java:comp/pm/TransactionManager". I wonder if they  
> could be configured to look for "java:/TransactionManager".
>
> I'm also wondering if throwing a RunTime exception is the  
> appropriate behavior, in this situation. Why not a NamingException?  
> I confess that the subtleties of JNDI are frequently lost on me...
>

I think a RuntimeException might be appropriate here..... there's a  
major logic problem in how the user is attempting to use jndi, this is  
not a problem due to someone forgetting to bind something in jndi.

thanks
david jencks


> --kevan

[kevan]

On Jun 26, 2009, at 12:15 PM, David Jencks wrote:

>
> On Jun 26, 2009, at 6:11 AM, Kevan Miller wrote:
>
>>
>> On Jun 26, 2009, at 3:26 AM, David Jencks wrote:
>>
>>>
>>> On Jun 26, 2009, at 12:02 AM, chander_bawa wrote:
>>>
>>>>
>>>> Thanks Djencks,
>>>> You are right. I tried deploying the ear from command line and  
>>>> faced the
>>>> same issue.
>>>> The thing is i am working on upgrading the geronimo server from  
>>>> 1.1.1 to
>>>> 2.1.4 and the application is working perfectly in 1.1.1
>>>> My confusion is why this error came when app is deployed on 2.1.4  
>>>> when it
>>>> worked perfectly on 1.1.1?
>>>
>>> The only reason I can think that this might work on 1.1.1 is that  
>>> we had a bug in the jndi implementation in 1.1.1 that lets the  
>>> lookup succeed.  It should fail on 1.1.1 just as it does on 2.1.4.
>>>
>>> If you answer the questions I asked in my previous reply I might  
>>> be able to suggest a way to proceed.  For instance you might be  
>>> able to look the destinations up in the jca:/ global jndi context.
>>
>> I don't think they're looking for destinations. Instead, it's  
>> looking for a TransactionManager. This same problem was reported  
>> back in April. That user reported that the oracle adapter was  
>> looking for "java:comp/pm/TransactionManager". I wonder if they  
>> could be configured to look for "java:/TransactionManager".
>>
>> I'm also wondering if throwing a RunTime exception is the  
>> appropriate behavior, in this situation. Why not a NamingException?  
>> I confess that the subtleties of JNDI are frequently lost on me...
>>
>
> I think a RuntimeException might be appropriate here..... there's a  
> major logic problem in how the user is attempting to use jndi, this  
> is not a problem due to someone forgetting to bind something in jndi.

Well, not necessarily a logic error. Code may be looking for a  
TransactionManager in a number of jndi locations. For example, see the  
following OpenJPA code -- http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/ee/AutomaticManagedRuntime.java?annotate=421741&pathrev=421741

They are catching Throwable, when looking for a TM in a number of  
locations. Don't know what Oracle is doing, here. But it sure sounds  
like they are treating a RuntimeException differently from a  
NamingException. You might argue that they should be more accepting.  
We've had two people report this problem. I'm just trying to see if we  
can/should *fix* the problem...

--kevan

[djencks]

On Jun 26, 2009, at 1:11 PM, Kevan Miller wrote:

>
> On Jun 26, 2009, at 12:15 PM, David Jencks wrote:
>
>>
>> On Jun 26, 2009, at 6:11 AM, Kevan Miller wrote:
>>
>>>
>>> On Jun 26, 2009, at 3:26 AM, David Jencks wrote:
>>>
>>>>
>>>> On Jun 26, 2009, at 12:02 AM, chander_bawa wrote:
>>>>
>>>>>
>>>>> Thanks Djencks,
>>>>> You are right. I tried deploying the ear from command line and  
>>>>> faced the
>>>>> same issue.
>>>>> The thing is i am working on upgrading the geronimo server from  
>>>>> 1.1.1 to
>>>>> 2.1.4 and the application is working perfectly in 1.1.1
>>>>> My confusion is why this error came when app is deployed on  
>>>>> 2.1.4 when it
>>>>> worked perfectly on 1.1.1?
>>>>
>>>> The only reason I can think that this might work on 1.1.1 is that  
>>>> we had a bug in the jndi implementation in 1.1.1 that lets the  
>>>> lookup succeed.  It should fail on 1.1.1 just as it does on 2.1.4.
>>>>
>>>> If you answer the questions I asked in my previous reply I might  
>>>> be able to suggest a way to proceed.  For instance you might be  
>>>> able to look the destinations up in the jca:/ global jndi context.
>>>
>>> I don't think they're looking for destinations. Instead, it's  
>>> looking for a TransactionManager. This same problem was reported  
>>> back in April. That user reported that the oracle adapter was  
>>> looking for "java:comp/pm/TransactionManager". I wonder if they  
>>> could be configured to look for "java:/TransactionManager".
>>>
>>> I'm also wondering if throwing a RunTime exception is the  
>>> appropriate behavior, in this situation. Why not a  
>>> NamingException? I confess that the subtleties of JNDI are  
>>> frequently lost on me...
>>>
>>
>> I think a RuntimeException might be appropriate here..... there's a  
>> major logic problem in how the user is attempting to use jndi, this  
>> is not a problem due to someone forgetting to bind something in jndi.
>
> Well, not necessarily a logic error. Code may be looking for a  
> TransactionManager in a number of jndi locations. For example, see  
> the following OpenJPA code -- http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/ee/AutomaticManagedRuntime.java?annotate=421741&pathrev=421741
>
> They are catching Throwable, when looking for a TM in a number of  
> locations. Don't know what Oracle is doing, here. But it sure sounds  
> like they are treating a RuntimeException differently from a  
> NamingException. You might argue that they should be more accepting.  
> We've had two people report this problem. I'm just trying to see if  
> we can/should *fix* the problem...

Ya, you're right... I guess NotContextException is probably good.

thanks
david jencks

>
> --kevan