Re: jndi-lookup fails, cured by tomcat restart
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dale, On 12/14/2010 6:13 PM, Dale Ogilvie wrote: > There are a few of them, examples below. Some work for us to track down > it would seem. > > SEVERE: The web application [/OLP] appears to have started a thread > named [ActiveMQ Scheduler] but has failed to stop it. This is very > likely to create a memory leak. Can you confirm that this thread is still running after context shutdown? Often, threads are in the process of stopping as the context is shutting down and you just have bad luck with a race condition that results in a report like this. Inspect the JVM a few seconds after the context has stopped to see if this thread has actually shut down. > SEVERE: The web application [/OLP] appears to have started a thread > named [InactivityMonitor Async Task: > java.util.concurrent.threadpoolexecutor$wor...@413fdef7[state = 0, empty > queue]] but has failed to stop it. This is very likely to create a > memory leak. Also, are there listeners you have launching things on init() but failing to call dispose(), destroy(), shutdown(), etc. on them in the destroy() method? > SEVERE: The web application [/OLP] appears to have started a thread > named [TcpSocketClose: > java.util.concurrent.threadpoolexecutor$wor...@d91afbc[state = 0, empty > queue]] but has failed to stop it. This is very likely to create a > memory leak. > SEVERE: The web application [/OLP] appears to have started a thread > named > [org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-1] > but has failed to stop it. This is very likely to create a memory leak. > SEVERE: The web application [/OLP] created a ThreadLocal with key of > type [java.lang.ThreadLocal] (value [java.lang.threadlo...@5fb5d830]) > and a value of type > org.springframework.security.core.context.SecurityContextImpl] (value > [org.springframework.security.core.context.securitycontexti...@: > Null authentication]) but failed to remove it when the web application > was stopped. This is very likely to create a memory leak. Finally, what version of Spring are you using? With the help of Tomcat's leak detection capabilities, many libraries have made improvements and eliminated these leaks... I believe that Spring is one of those libraries. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0JD7kACgkQ9CaO5/Lv0PBTewCaApLWkTZkDWnglEZmBpeJoGpJ Ek4AoJ/c8PWvwS5wabF++SnTnpYbQSTQ =nncP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: jndi-lookup fails, cured by tomcat restart
There are a few of them, examples below. Some work for us to track down it would seem. SEVERE: The web application [/OLP] appears to have started a thread named [ActiveMQ Scheduler] but has failed to stop it. This is very likely to create a memory leak. SEVERE: The web application [/OLP] appears to have started a thread named [InactivityMonitor Async Task: java.util.concurrent.threadpoolexecutor$wor...@413fdef7[state = 0, empty queue]] but has failed to stop it. This is very likely to create a memory leak. SEVERE: The web application [/OLP] appears to have started a thread named [TcpSocketClose: java.util.concurrent.threadpoolexecutor$wor...@d91afbc[state = 0, empty queue]] but has failed to stop it. This is very likely to create a memory leak. SEVERE: The web application [/OLP] appears to have started a thread named [org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-1] but has failed to stop it. This is very likely to create a memory leak. SEVERE: The web application [/OLP] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@5fb5d830]) and a value of type org.springframework.security.core.context.SecurityContextImpl] (value [org.springframework.security.core.context.securitycontexti...@: Null authentication]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. -Original Message- From: Pid [mailto:p...@pidster.com] Sent: Wednesday, 15 December 2010 12:00 p.m. To: Tomcat Users List Subject: Re: jndi-lookup fails, cured by tomcat restart On 14/12/2010 22:35, Dale Ogilvie wrote: > > We'll investigate the leak issue, there /are/ leaks from Spring active > mq code. Mind posting the leak warning from the logs? p > -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Wednesday, 15 December 2010 11:15 a.m. > To: Tomcat Users List > Subject: Re: jndi-lookup fails, cured by tomcat restart > > Dave, > > On 12/14/2010 4:56 PM, Dale Ogilvie wrote: >> Redeployment that first caused the issue was using manager web-app. >> We > >> tried other deployment options after that. > >> OS is RHEL5.x > >> Aha, scanning the logs around the first error I found the following >> in > >> catalina.2010-12-08.log. This message (and friends) is appearing >> prior > >> to the first failure to deploy our app. > >> Dec 8, 2010 7:09:33 PM >> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor >> processChildren >> SEVERE: Exception invoking periodic operation: >> java.lang.OutOfMemoryError: PermGen space > > If you start Tomcat fresh, deploy your webapp, then undeploy, do you > get any warnings about memory leaks? The manager webapp has a "Find Leaks" > button that you can click to see if Tomcat has detected any leaks. > > If there /are/ leaks, it means that multiple re-deployments will > ultimately lead to permgen exhaustion. > > -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jndi-lookup fails, cured by tomcat restart
On 14/12/2010 22:35, Dale Ogilvie wrote: > > We'll investigate the leak issue, there /are/ leaks from Spring active > mq code. Mind posting the leak warning from the logs? p > -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Wednesday, 15 December 2010 11:15 a.m. > To: Tomcat Users List > Subject: Re: jndi-lookup fails, cured by tomcat restart > > Dave, > > On 12/14/2010 4:56 PM, Dale Ogilvie wrote: >> Redeployment that first caused the issue was using manager web-app. We > >> tried other deployment options after that. > >> OS is RHEL5.x > >> Aha, scanning the logs around the first error I found the following in > >> catalina.2010-12-08.log. This message (and friends) is appearing prior > >> to the first failure to deploy our app. > >> Dec 8, 2010 7:09:33 PM >> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor >> processChildren >> SEVERE: Exception invoking periodic operation: >> java.lang.OutOfMemoryError: PermGen space > > If you start Tomcat fresh, deploy your webapp, then undeploy, do you get > any warnings about memory leaks? The manager webapp has a "Find Leaks" > button that you can click to see if Tomcat has detected any leaks. > > If there /are/ leaks, it means that multiple re-deployments will > ultimately lead to permgen exhaustion. > > -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
RE: jndi-lookup fails, cured by tomcat restart
We'll investigate the leak issue, there /are/ leaks from Spring active mq code. -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, 15 December 2010 11:15 a.m. To: Tomcat Users List Subject: Re: jndi-lookup fails, cured by tomcat restart -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave, On 12/14/2010 4:56 PM, Dale Ogilvie wrote: > Redeployment that first caused the issue was using manager web-app. We > tried other deployment options after that. > > OS is RHEL5.x > > Aha, scanning the logs around the first error I found the following in > catalina.2010-12-08.log. This message (and friends) is appearing prior > to the first failure to deploy our app. > > Dec 8, 2010 7:09:33 PM > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor > processChildren > SEVERE: Exception invoking periodic operation: > java.lang.OutOfMemoryError: PermGen space If you start Tomcat fresh, deploy your webapp, then undeploy, do you get any warnings about memory leaks? The manager webapp has a "Find Leaks" button that you can click to see if Tomcat has detected any leaks. If there /are/ leaks, it means that multiple re-deployments will ultimately lead to permgen exhaustion. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0H7H4ACgkQ9CaO5/Lv0PC80gCgobxkhO7O5qMcxtFBGB6t39PX etwAnjwEPiJmpeyxqdGJg5DzWNkz/SAX =vfMa -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jndi-lookup fails, cured by tomcat restart
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave, On 12/14/2010 4:56 PM, Dale Ogilvie wrote: > Redeployment that first caused the issue was using manager web-app. We > tried other deployment options after that. > > OS is RHEL5.x > > Aha, scanning the logs around the first error I found the following in > catalina.2010-12-08.log. This message (and friends) is appearing prior > to the first failure to deploy our app. > > Dec 8, 2010 7:09:33 PM > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor > processChildren > SEVERE: Exception invoking periodic operation: > java.lang.OutOfMemoryError: PermGen space If you start Tomcat fresh, deploy your webapp, then undeploy, do you get any warnings about memory leaks? The manager webapp has a "Find Leaks" button that you can click to see if Tomcat has detected any leaks. If there /are/ leaks, it means that multiple re-deployments will ultimately lead to permgen exhaustion. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0H7H4ACgkQ9CaO5/Lv0PC80gCgobxkhO7O5qMcxtFBGB6t39PX etwAnjwEPiJmpeyxqdGJg5DzWNkz/SAX =vfMa -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: jndi-lookup fails, cured by tomcat restart
I am not the developer who caused the issue, but... Redeployment that first caused the issue was using manager web-app. We tried other deployment options after that. OS is RHEL5.x Aha, scanning the logs around the first error I found the following in catalina.2010-12-08.log. This message (and friends) is appearing prior to the first failure to deploy our app. Dec 8, 2010 7:09:33 PM org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren SEVERE: Exception invoking periodic operation: java.lang.OutOfMemoryError: PermGen space An out-of-resource error such as this is quite likely the cause, any comments from anyone as to the likely cause, or troubleshooting? Follows our tomcat process info, we use MaxPermSize 512M tomcat6 13184 0.2 27.0 2018392 538840 ? Sl Dec12 6:21 /usr/lib/jvm/java-1.6.0/bin/java -Xms512M -Xmx1G -XX:MaxPermSize=512M -Djava.library.path=/opt/apache-tomcat/lib -classpath :/opt/apache-tomcat/bin/bootstrap.jar:/opt/apache-tomcat/bin/tomcat-juli .jar: -Dcatalina.base=/opt/apache-tomcat -Dcatalina.home=/opt/apache-tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/opt/apache-tomcat/temp -Djava.util.logging.config.file=/opt/apache-tomcat/conf/logging.properti es -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Wednesday, 15 December 2010 5:42 a.m. To: Tomcat Users List Subject: Re: jndi-lookup fails, cured by tomcat restart 2010/12/14 Dale Ogilvie : > > The thing is that the code is working fine now, without the fully > qualified jndi-name. IIRC, Spring adds a prefix to the name before doing the lookup (as seen from the logs fragment). How do you perform your deployment? Do you use the manager webapp, or rely on autodeployment? When dealing with the context.xml file the usual caveat is when there is a stale copy of it in conf/Catalina/localhost/ Anything else in the logs? Are there messages before your app tries to start up? (E.g. Tomcat reporting that the app was deployed)? What is your OS? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: jndi-lookup fails, cured by tomcat restart
Thanks for that clarification. -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Tuesday, 14 December 2010 11:23 p.m. To: Tomcat Users List Subject: Re: jndi-lookup fails, cured by tomcat restart On 13/12/2010 22:52, Dale Ogilvie wrote: > > propsFileName is the name of the bean, which should be initialized > with the string value from the JNDI entry "propertiesFileName" defined > in $CATALINA_HOME/conf/context.xml > > This was working, stopped working until a tomcat restart, and is > working again now. My concern is that this may be a bug in tomcat > > So what happens is that tomcat startup creates a JNDI environment > entry in the "cross-application" context called "propertiesFileName". Just to be clear, there is no global or cross-application context. Entries in CATALINA_BASE/conf/context.xml are merged with the application's context.xml and become part of the application's context configuration. This means that if you define a resource in CATALINA_BASE/conf/context.xml and you have 20 contexts you will get 20 instances of that resource - one for each context. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jndi-lookup fails, cured by tomcat restart
2010/12/14 Dale Ogilvie : > > The thing is that the code is working fine now, without the fully > qualified jndi-name. IIRC, Spring adds a prefix to the name before doing the lookup (as seen from the logs fragment). How do you perform your deployment? Do you use the manager webapp, or rely on autodeployment? When dealing with the context.xml file the usual caveat is when there is a stale copy of it in conf/Catalina/localhost/ Anything else in the logs? Are there messages before your app tries to start up? (E.g. Tomcat reporting that the app was deployed)? What is your OS? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jndi-lookup fails, cured by tomcat restart
On 14/12/2010 01:28, Dale Ogilvie wrote: > > The thing is that the code is working fine now, without the fully > qualified jndi-name. Then an app redeployment and it stopped working. > Then an apache restart and it started working again... > > I found something on Google about having apache jars in WEB-INF/lib, but > I don't think this was/is the case for our app. There's an alternative: do you have spring (or other non-Tomcat) jars in tomcat/lib? If so, what are they? p > http://java.ittoolbox.com/groups/technical-functional/jsp-l/javaxnamingn > amenotfoundexception-name-javacomp-is-not-bound-in-this-context-3603504 > > > -Original Message- > From: Mark Eggers [mailto:its_toas...@yahoo.com] > Sent: Tuesday, 14 December 2010 12:46 p.m. > To: Tomcat Users List > Subject: Re: jndi-lookup fails, cured by tomcat restart > > Dale, > > What happens if you try changing the jndi-name to its fully qualified > version? > > java:comp/env/propertiesFileName > > Then change the context.xml file name to propertiesFileName (no leading > slash)? > > I'm basing these comments on some similar issues I've seen in the Spring > forums, and similar configuration issues when using Hibernate with > Tomcat. > > Don't ask me to explain why this worked for a long time, and then all of > a suddenly decided not to work. > > Hope this helps. > > . . . . just a guess. > > /mde/ > > > - Original Message > From: Dale Ogilvie > To: Tomcat Users List > Sent: Mon, December 13, 2010 2:52:09 PM > Subject: RE: jndi-lookup fails, cured by tomcat restart > > > propsFileName is the name of the bean, which should be initialized with > the string value from the JNDI entry "propertiesFileName" defined in > $CATALINA_HOME/conf/context.xml > > This was working, stopped working until a tomcat restart, and is working > again now. My concern is that this may be a bug in tomcat > > So what happens is that tomcat startup creates a JNDI environment entry > in the "cross-application" context called "propertiesFileName". > > value="classpath:test-application.properties" type="java.lang.String" > override="true"/> > > When each spring app starts, the code id="propsFileName" jndi-name="propertiesFileName"/> in the application > context takes the JNDI environment entry and initializes a bean using > the id "propsFileName" with it. > > Finally a spring PropertyPlaceholderConfigurer is created using the > propsFileName bean for the location of the properties file. We use this > to > > class="org.springframework.beans.factory.config.PropertyPlaceholderConfi > gurer"> > > > > Looking more closely at the debug log, this line looks quite suspicious > "Name comp is not bound". comp is the root of the environment hierarchy, > why would that be missing? > > 2010-12-08 19:29:11,161 DEBUG ** Converted JNDI name > [java:comp/env/propertiesFileName] not found - trying original name > [propertiesFileName]. javax.naming.NameNotFoundException: Name comp is > not bound in this Context ** > org.springframework.jndi.JndiObjectFactoryBean > > Log context follows: > > 2010-12-08 19:29:11,108 DEBUG ** Creating instance of bean > 'propsFileName' ** > org.springframework.beans.factory.support.DefaultListableBeanFactory > 2010-12-08 19:29:11,116 DEBUG ** Eagerly caching bean 'propsFileName' to > allow for resolving potential circular references ** > org.springframework.beans.factory.support.DefaultListableBeanFactory > 2010-12-08 19:29:11,158 DEBUG ** Invoking afterPropertiesSet() on bean > with name 'propsFileName' ** > org.springframework.beans.factory.support.DefaultListableBeanFactory > 2010-12-08 19:29:11,158 DEBUG ** Looking up JNDI object with name > [java:comp/env/propertiesFileName] ** > org.springframework.jndi.JndiTemplate > 2010-12-08 19:29:11,161 DEBUG ** Converted JNDI name > [java:comp/env/propertiesFileName] not found - trying original name > [propertiesFileName]. javax.naming.NameNotFoundException: Name comp is > not bound in this Context ** > org.springframework.jndi.JndiObjectFactoryBean > 2010-12-08 19:29:11,161 DEBUG ** Looking up JNDI object with name > [propertiesFileName] ** org.springframework.jndi.JndiTemplate > 2010-12-08 19:29:11,164 INFO ** Destroying singletons in > org.springframework.beans.factory.support.defaultlistablebeanfact...@493 > 02473: defining beans > [propsFileName,org.springframework.beans.factory.config.PropertyPlacehol > derConfigure > 2010-12-08 19:29:11,165 ERRO
Re: jndi-lookup fails, cured by tomcat restart
On 14/12/2010 10:33, Mark Thomas wrote: > On 14/12/2010 01:28, Dale Ogilvie wrote: >> >> The thing is that the code is working fine now, without the fully >> qualified jndi-name. Then an app redeployment and it stopped working. >> Then an apache restart and it started working again... > > That does sound like a bug. Let me see if I can re-create it... Tested this with the latest 6.0.x and 7.0.x and both work as expected. This looks like an application issue at this point. We'll need a reproducible test case (minimal changes from a clean Tomcat install) to look at this further. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jndi-lookup fails, cured by tomcat restart
On 14/12/2010 01:28, Dale Ogilvie wrote: > > The thing is that the code is working fine now, without the fully > qualified jndi-name. Then an app redeployment and it stopped working. > Then an apache restart and it started working again... That does sound like a bug. Let me see if I can re-create it... Mark > > I found something on Google about having apache jars in WEB-INF/lib, but > I don't think this was/is the case for our app. > > http://java.ittoolbox.com/groups/technical-functional/jsp-l/javaxnamingn > amenotfoundexception-name-javacomp-is-not-bound-in-this-context-3603504 > > > -Original Message- > From: Mark Eggers [mailto:its_toas...@yahoo.com] > Sent: Tuesday, 14 December 2010 12:46 p.m. > To: Tomcat Users List > Subject: Re: jndi-lookup fails, cured by tomcat restart > > Dale, > > What happens if you try changing the jndi-name to its fully qualified > version? > > java:comp/env/propertiesFileName > > Then change the context.xml file name to propertiesFileName (no leading > slash)? > > I'm basing these comments on some similar issues I've seen in the Spring > forums, and similar configuration issues when using Hibernate with > Tomcat. > > Don't ask me to explain why this worked for a long time, and then all of > a suddenly decided not to work. > > Hope this helps. > > . . . . just a guess. > > /mde/ > > > ----- Original Message ---- > From: Dale Ogilvie > To: Tomcat Users List > Sent: Mon, December 13, 2010 2:52:09 PM > Subject: RE: jndi-lookup fails, cured by tomcat restart > > > propsFileName is the name of the bean, which should be initialized with > the string value from the JNDI entry "propertiesFileName" defined in > $CATALINA_HOME/conf/context.xml > > This was working, stopped working until a tomcat restart, and is working > again now. My concern is that this may be a bug in tomcat > > So what happens is that tomcat startup creates a JNDI environment entry > in the "cross-application" context called "propertiesFileName". > > value="classpath:test-application.properties" type="java.lang.String" > override="true"/> > > When each spring app starts, the code id="propsFileName" jndi-name="propertiesFileName"/> in the application > context takes the JNDI environment entry and initializes a bean using > the id "propsFileName" with it. > > Finally a spring PropertyPlaceholderConfigurer is created using the > propsFileName bean for the location of the properties file. We use this > to > > class="org.springframework.beans.factory.config.PropertyPlaceholderConfi > gurer"> > > > > Looking more closely at the debug log, this line looks quite suspicious > "Name comp is not bound". comp is the root of the environment hierarchy, > why would that be missing? > > 2010-12-08 19:29:11,161 DEBUG ** Converted JNDI name > [java:comp/env/propertiesFileName] not found - trying original name > [propertiesFileName]. javax.naming.NameNotFoundException: Name comp is > not bound in this Context ** > org.springframework.jndi.JndiObjectFactoryBean > > Log context follows: > > 2010-12-08 19:29:11,108 DEBUG ** Creating instance of bean > 'propsFileName' ** > org.springframework.beans.factory.support.DefaultListableBeanFactory > 2010-12-08 19:29:11,116 DEBUG ** Eagerly caching bean 'propsFileName' to > allow for resolving potential circular references ** > org.springframework.beans.factory.support.DefaultListableBeanFactory > 2010-12-08 19:29:11,158 DEBUG ** Invoking afterPropertiesSet() on bean > with name 'propsFileName' ** > org.springframework.beans.factory.support.DefaultListableBeanFactory > 2010-12-08 19:29:11,158 DEBUG ** Looking up JNDI object with name > [java:comp/env/propertiesFileName] ** > org.springframework.jndi.JndiTemplate > 2010-12-08 19:29:11,161 DEBUG ** Converted JNDI name > [java:comp/env/propertiesFileName] not found - trying original name > [propertiesFileName]. javax.naming.NameNotFoundException: Name comp is > not bound in this Context ** > org.springframework.jndi.JndiObjectFactoryBean > 2010-12-08 19:29:11,161 DEBUG ** Looking up JNDI object with name > [propertiesFileName] ** org.springframework.jndi.JndiTemplate > 2010-12-08 19:29:11,164 INFO ** Destroying singletons in > org.springframework.beans.factory.support.defaultlistablebeanfact...@493 > 02473: defining beans > [propsFileName,org.springframework.beans.factory.config.PropertyPlacehol > derConfigure > 2010-12-08 19:29:11,165 ERROR ** Context initialization failed
Re: jndi-lookup fails, cured by tomcat restart
On 13/12/2010 22:52, Dale Ogilvie wrote: > > propsFileName is the name of the bean, which should be initialized with > the string value from the JNDI entry "propertiesFileName" defined in > $CATALINA_HOME/conf/context.xml > > This was working, stopped working until a tomcat restart, and is working > again now. My concern is that this may be a bug in tomcat > > So what happens is that tomcat startup creates a JNDI environment entry > in the "cross-application" context called "propertiesFileName". Just to be clear, there is no global or cross-application context. Entries in CATALINA_BASE/conf/context.xml are merged with the application's context.xml and become part of the application's context configuration. This means that if you define a resource in CATALINA_BASE/conf/context.xml and you have 20 contexts you will get 20 instances of that resource - one for each context. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: jndi-lookup fails, cured by tomcat restart
The thing is that the code is working fine now, without the fully qualified jndi-name. Then an app redeployment and it stopped working. Then an apache restart and it started working again... I found something on Google about having apache jars in WEB-INF/lib, but I don't think this was/is the case for our app. http://java.ittoolbox.com/groups/technical-functional/jsp-l/javaxnamingn amenotfoundexception-name-javacomp-is-not-bound-in-this-context-3603504 -Original Message- From: Mark Eggers [mailto:its_toas...@yahoo.com] Sent: Tuesday, 14 December 2010 12:46 p.m. To: Tomcat Users List Subject: Re: jndi-lookup fails, cured by tomcat restart Dale, What happens if you try changing the jndi-name to its fully qualified version? java:comp/env/propertiesFileName Then change the context.xml file name to propertiesFileName (no leading slash)? I'm basing these comments on some similar issues I've seen in the Spring forums, and similar configuration issues when using Hibernate with Tomcat. Don't ask me to explain why this worked for a long time, and then all of a suddenly decided not to work. Hope this helps. . . . . just a guess. /mde/ - Original Message From: Dale Ogilvie To: Tomcat Users List Sent: Mon, December 13, 2010 2:52:09 PM Subject: RE: jndi-lookup fails, cured by tomcat restart propsFileName is the name of the bean, which should be initialized with the string value from the JNDI entry "propertiesFileName" defined in $CATALINA_HOME/conf/context.xml This was working, stopped working until a tomcat restart, and is working again now. My concern is that this may be a bug in tomcat So what happens is that tomcat startup creates a JNDI environment entry in the "cross-application" context called "propertiesFileName". When each spring app starts, the code in the application context takes the JNDI environment entry and initializes a bean using the id "propsFileName" with it. Finally a spring PropertyPlaceholderConfigurer is created using the propsFileName bean for the location of the properties file. We use this to Looking more closely at the debug log, this line looks quite suspicious "Name comp is not bound". comp is the root of the environment hierarchy, why would that be missing? 2010-12-08 19:29:11,161 DEBUG ** Converted JNDI name [java:comp/env/propertiesFileName] not found - trying original name [propertiesFileName]. javax.naming.NameNotFoundException: Name comp is not bound in this Context ** org.springframework.jndi.JndiObjectFactoryBean Log context follows: 2010-12-08 19:29:11,108 DEBUG ** Creating instance of bean 'propsFileName' ** org.springframework.beans.factory.support.DefaultListableBeanFactory 2010-12-08 19:29:11,116 DEBUG ** Eagerly caching bean 'propsFileName' to allow for resolving potential circular references ** org.springframework.beans.factory.support.DefaultListableBeanFactory 2010-12-08 19:29:11,158 DEBUG ** Invoking afterPropertiesSet() on bean with name 'propsFileName' ** org.springframework.beans.factory.support.DefaultListableBeanFactory 2010-12-08 19:29:11,158 DEBUG ** Looking up JNDI object with name [java:comp/env/propertiesFileName] ** org.springframework.jndi.JndiTemplate 2010-12-08 19:29:11,161 DEBUG ** Converted JNDI name [java:comp/env/propertiesFileName] not found - trying original name [propertiesFileName]. javax.naming.NameNotFoundException: Name comp is not bound in this Context ** org.springframework.jndi.JndiObjectFactoryBean 2010-12-08 19:29:11,161 DEBUG ** Looking up JNDI object with name [propertiesFileName] ** org.springframework.jndi.JndiTemplate 2010-12-08 19:29:11,164 INFO ** Destroying singletons in org.springframework.beans.factory.support.defaultlistablebeanfact...@493 02473: defining beans [propsFileName,org.springframework.beans.factory.config.PropertyPlacehol derConfigure 2010-12-08 19:29:11,165 ERROR ** Context initialization failed ** org.springframework.web.context.ContextLoader -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, 14 December 2010 9:46 a.m. To: Tomcat Users List Subject: Re: jndi-lookup fails, cured by tomcat restart -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dale, On 12/13/2010 3:08 PM, Dale Ogilvie wrote: > We are using a spring jndi-lookup to pull the name of a context file > from the global "environment" in our apps. We have set this up in > tomcat > 6.0.29 like so: > > $CATALINA_HOME/conf/context.xml Technically speaking, I think that's the default local environment, not the global environment. You can define entries at the level in server.xml which would be truly "global". It's all semantics for this discussion and shouldn't impact this case. > value="classpath:test-application.properties" type="java.lang.String"
Re: jndi-lookup fails, cured by tomcat restart
Dale, What happens if you try changing the jndi-name to its fully qualified version? java:comp/env/propertiesFileName Then change the context.xml file name to propertiesFileName (no leading slash)? I'm basing these comments on some similar issues I've seen in the Spring forums, and similar configuration issues when using Hibernate with Tomcat. Don't ask me to explain why this worked for a long time, and then all of a suddenly decided not to work. Hope this helps. . . . . just a guess. /mde/ - Original Message From: Dale Ogilvie To: Tomcat Users List Sent: Mon, December 13, 2010 2:52:09 PM Subject: RE: jndi-lookup fails, cured by tomcat restart propsFileName is the name of the bean, which should be initialized with the string value from the JNDI entry "propertiesFileName" defined in $CATALINA_HOME/conf/context.xml This was working, stopped working until a tomcat restart, and is working again now. My concern is that this may be a bug in tomcat So what happens is that tomcat startup creates a JNDI environment entry in the "cross-application" context called "propertiesFileName". When each spring app starts, the code in the application context takes the JNDI environment entry and initializes a bean using the id "propsFileName" with it. Finally a spring PropertyPlaceholderConfigurer is created using the propsFileName bean for the location of the properties file. We use this to Looking more closely at the debug log, this line looks quite suspicious "Name comp is not bound". comp is the root of the environment hierarchy, why would that be missing? 2010-12-08 19:29:11,161 DEBUG ** Converted JNDI name [java:comp/env/propertiesFileName] not found - trying original name [propertiesFileName]. javax.naming.NameNotFoundException: Name comp is not bound in this Context ** org.springframework.jndi.JndiObjectFactoryBean Log context follows: 2010-12-08 19:29:11,108 DEBUG ** Creating instance of bean 'propsFileName' ** org.springframework.beans.factory.support.DefaultListableBeanFactory 2010-12-08 19:29:11,116 DEBUG ** Eagerly caching bean 'propsFileName' to allow for resolving potential circular references ** org.springframework.beans.factory.support.DefaultListableBeanFactory 2010-12-08 19:29:11,158 DEBUG ** Invoking afterPropertiesSet() on bean with name 'propsFileName' ** org.springframework.beans.factory.support.DefaultListableBeanFactory 2010-12-08 19:29:11,158 DEBUG ** Looking up JNDI object with name [java:comp/env/propertiesFileName] ** org.springframework.jndi.JndiTemplate 2010-12-08 19:29:11,161 DEBUG ** Converted JNDI name [java:comp/env/propertiesFileName] not found - trying original name [propertiesFileName]. javax.naming.NameNotFoundException: Name comp is not bound in this Context ** org.springframework.jndi.JndiObjectFactoryBean 2010-12-08 19:29:11,161 DEBUG ** Looking up JNDI object with name [propertiesFileName] ** org.springframework.jndi.JndiTemplate 2010-12-08 19:29:11,164 INFO ** Destroying singletons in org.springframework.beans.factory.support.defaultlistablebeanfact...@493 02473: defining beans [propsFileName,org.springframework.beans.factory.config.PropertyPlacehol derConfigure 2010-12-08 19:29:11,165 ERROR ** Context initialization failed ** org.springframework.web.context.ContextLoader -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, 14 December 2010 9:46 a.m. To: Tomcat Users List Subject: Re: jndi-lookup fails, cured by tomcat restart -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dale, On 12/13/2010 3:08 PM, Dale Ogilvie wrote: > We are using a spring jndi-lookup to pull the name of a context file > from the global "environment" in our apps. We have set this up in > tomcat > 6.0.29 like so: > > $CATALINA_HOME/conf/context.xml Technically speaking, I think that's the default local environment, not the global environment. You can define entries at the level in server.xml which would be truly "global". It's all semantics for this discussion and shouldn't impact this case. > value="classpath:test-application.properties" type="java.lang.String" > override="true"/> > > This has worked fine for lots of applications, but last week it > started failing for one application when it was redeployed. This > results in the application failing to start. > > The error message below suggests that the environment value cannot be > found. > > Tomcat 6.0.29 log output: > > 2010-12-08 19:27:24,674 DEBUG ** Invoking afterPropertiesSet() on bean > with name 'propsFileName' ** 'propsFileName' != 'propertiesFileName' Are you sure you're looking at the right configuration file? > org.springframework.beans.factory.B
RE: jndi-lookup fails, cured by tomcat restart
propsFileName is the name of the bean, which should be initialized with the string value from the JNDI entry "propertiesFileName" defined in $CATALINA_HOME/conf/context.xml This was working, stopped working until a tomcat restart, and is working again now. My concern is that this may be a bug in tomcat So what happens is that tomcat startup creates a JNDI environment entry in the "cross-application" context called "propertiesFileName". When each spring app starts, the code in the application context takes the JNDI environment entry and initializes a bean using the id "propsFileName" with it. Finally a spring PropertyPlaceholderConfigurer is created using the propsFileName bean for the location of the properties file. We use this to Looking more closely at the debug log, this line looks quite suspicious "Name comp is not bound". comp is the root of the environment hierarchy, why would that be missing? 2010-12-08 19:29:11,161 DEBUG ** Converted JNDI name [java:comp/env/propertiesFileName] not found - trying original name [propertiesFileName]. javax.naming.NameNotFoundException: Name comp is not bound in this Context ** org.springframework.jndi.JndiObjectFactoryBean Log context follows: 2010-12-08 19:29:11,108 DEBUG ** Creating instance of bean 'propsFileName' ** org.springframework.beans.factory.support.DefaultListableBeanFactory 2010-12-08 19:29:11,116 DEBUG ** Eagerly caching bean 'propsFileName' to allow for resolving potential circular references ** org.springframework.beans.factory.support.DefaultListableBeanFactory 2010-12-08 19:29:11,158 DEBUG ** Invoking afterPropertiesSet() on bean with name 'propsFileName' ** org.springframework.beans.factory.support.DefaultListableBeanFactory 2010-12-08 19:29:11,158 DEBUG ** Looking up JNDI object with name [java:comp/env/propertiesFileName] ** org.springframework.jndi.JndiTemplate 2010-12-08 19:29:11,161 DEBUG ** Converted JNDI name [java:comp/env/propertiesFileName] not found - trying original name [propertiesFileName]. javax.naming.NameNotFoundException: Name comp is not bound in this Context ** org.springframework.jndi.JndiObjectFactoryBean 2010-12-08 19:29:11,161 DEBUG ** Looking up JNDI object with name [propertiesFileName] ** org.springframework.jndi.JndiTemplate 2010-12-08 19:29:11,164 INFO ** Destroying singletons in org.springframework.beans.factory.support.defaultlistablebeanfact...@493 02473: defining beans [propsFileName,org.springframework.beans.factory.config.PropertyPlacehol derConfigure 2010-12-08 19:29:11,165 ERROR ** Context initialization failed ** org.springframework.web.context.ContextLoader -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, 14 December 2010 9:46 a.m. To: Tomcat Users List Subject: Re: jndi-lookup fails, cured by tomcat restart -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dale, On 12/13/2010 3:08 PM, Dale Ogilvie wrote: > We are using a spring jndi-lookup to pull the name of a context file > from the global "environment" in our apps. We have set this up in > tomcat > 6.0.29 like so: > > $CATALINA_HOME/conf/context.xml Technically speaking, I think that's the default local environment, not the global environment. You can define entries at the level in server.xml which would be truly "global". It's all semantics for this discussion and shouldn't impact this case. > value="classpath:test-application.properties" type="java.lang.String" > override="true"/> > > This has worked fine for lots of applications, but last week it > started failing for one application when it was redeployed. This > results in the application failing to start. > > The error message below suggests that the environment value cannot be > found. > > Tomcat 6.0.29 log output: > > 2010-12-08 19:27:24,674 DEBUG ** Invoking afterPropertiesSet() on bean > with name 'propsFileName' ** 'propsFileName' != 'propertiesFileName' Are you sure you're looking at the right configuration file? > org.springframework.beans.factory.BeanCreationException: Error > creating bean with name 'propsFileName': Invocation of init method > failed; nested exception is javax.naming.NameNotFoundException: Name > propertiesFileName is not bound in this Context Perhaps propsFileName is bound, but not propertiesFileName. > Spring application web.xml > > > contextConfigLocation > > classpath:applicationContext-shared.xml > > > > > > org.springframework.web.context.ContextLoaderListener< > /l > istener-class> > > > applicationContext-Shared.xml > > /> > > class="
Re: jndi-lookup fails, cured by tomcat restart
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dale, On 12/13/2010 3:08 PM, Dale Ogilvie wrote: > We are using a spring jndi-lookup to pull the name of a context file > from the global "environment" in our apps. We have set this up in tomcat > 6.0.29 like so: > > $CATALINA_HOME/conf/context.xml Technically speaking, I think that's the default local environment, not the global environment. You can define entries at the level in server.xml which would be truly "global". It's all semantics for this discussion and shouldn't impact this case. > value="classpath:test-application.properties" type="java.lang.String" > override="true"/> > > This has worked fine for lots of applications, but last week it started > failing for one application when it was redeployed. This results in the > application failing to start. > > The error message below suggests that the environment value cannot be > found. > > Tomcat 6.0.29 log output: > > 2010-12-08 19:27:24,674 DEBUG ** Invoking afterPropertiesSet() on bean > with name 'propsFileName' ** 'propsFileName' != 'propertiesFileName' Are you sure you're looking at the right configuration file? > org.springframework.beans.factory.BeanCreationException: Error creating > bean with name 'propsFileName': Invocation of init method failed; nested > exception is javax.naming.NameNotFoundException: Name propertiesFileName > is not bound in this Context Perhaps propsFileName is bound, but not propertiesFileName. > Spring application web.xml > > > contextConfigLocation > > classpath:applicationContext-shared.xml > > > > > > org.springframework.web.context.ContextLoaderListener istener-class> > > > applicationContext-Shared.xml > > /> > > class="org.springframework.beans.factory.config.PropertyPlaceholderConfi > gurer"> > > I don't see where the data is ultimately defined... I just see a bunch of references that don't point to anything. propertiesFileName -> propsFileName -> ??? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0GhfkACgkQ9CaO5/Lv0PB5OQCfa20jn6k8gt/jvp211sFgA+KZ YRsAn3FFKu9rx2BidCKz64FKo+Vnb7LO =HtIz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
