Re: [logback-user] jndi db access in tomcat5.5
Hello Diego, [1]
using tomcat5.5, username/password can't be specified when trying to use a JNDI-shared DataSource when using pooled data sources the user and password version of getConnection method can't be used. I don't know if this is tomcat-specific behaviour.
this is indeed an iteresting question; do we have anybody here with a better knowledge of J2EE?
... in ... ch.qos.logback.core.db.JNDIConnectionSource: Maybe some sort of "if jndi then don't use user/pass" testing could be done for better error reporting
I guess if the answer to prev. question is positive this could be a worthy idea [2]
Added to that, the JNDI name used in the "jndiLocation" must be prepended by "java:comp/env", as this is the standard context for java objects and the JNDIConnectionSource does not prepend the searched values with it.
Looks like a nice idea to me. Will not be backwards compatible but logback is not version 1 yet. I suggest that you create a Jira item for this /and maybe attach a patch/ [3]
Another thing I got problems with was slf4j's jcl-over-slf4j-1.5.2.jar. logback ... initialized too early when using jcl-over-slf4j, before tomcat makes the JNDI resources available to the web application
ch.qos.logback.core.db.JNDIConnectionSource@67c1a6 - Error while getting data source javax.naming.NameNotFoundException: javax.naming.NameNotFoundException: 'comp' can't be found in this context at org.apache.naming.NamingContext.lookup(NamingContext.java:770) ... org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155) org.apache.commons.logging.LogFactory.getLog(LogFactory.java:704) org.apache.catalina.core.ContainerBase.getLogger(ContainerBase.java:381) ... org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)
Looks pretty weird to me. Diego what folder is jcl-over-slf4j-1.5.2.jar in? Do you have another copy in shared tomcat libraries? Or together with tomcat own jars? Cheers, Anton Tagunov logback user
Thanks for the quick answer, see inline response. Anton Tagunov escribió:
Hello Diego,
[1]
using tomcat5.5, username/password can't be specified when trying to use a JNDI-shared DataSource when using pooled data sources the user and password version of getConnection method can't be used. I don't know if this is tomcat-specific behaviour.
this is indeed an iteresting question; do we have anybody here with a better knowledge of J2EE?
... in ... ch.qos.logback.core.db.JNDIConnectionSource: Maybe some sort of "if jndi then don't use user/pass" testing could be done for better error reporting
I guess if the answer to prev. question is positive this could be a worthy idea
[2]
Added to that, the JNDI name used in the "jndiLocation" must be prepended by "java:comp/env", as this is the standard context for java objects and the JNDIConnectionSource does not prepend the searched values with it.
Looks like a nice idea to me. Will not be backwards compatible but logback is not version 1 yet. I suggest that you create a Jira item for this /and maybe attach a patch/
In my company we have our own DataSourceLocator class that abstracts the JNDI lookup and automagically prepends all searched keys with "java:comp/env" but this is obviously custom behaviour. There are two options here: document the need for the prefix in the manual or add the prefix to all keys in the JNDIConnectionSource class. I'd suggest the former option as the best one, but as you already pointed out, backwards compatibility is lost in the way.
[3]
Another thing I got problems with was slf4j's jcl-over-slf4j-1.5.2.jar. logback ... initialized too early when using jcl-over-slf4j, before tomcat makes the JNDI resources available to the web application
ch.qos.logback.core.db.JNDIConnectionSource@67c1a6 - Error while getting data source javax.naming.NameNotFoundException: javax.naming.NameNotFoundException: 'comp' can't be found in this context at org.apache.naming.NamingContext.lookup(NamingContext.java:770) ... org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155) org.apache.commons.logging.LogFactory.getLog(LogFactory.java:704) org.apache.catalina.core.ContainerBase.getLogger(ContainerBase.java:381) ... org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)
Looks pretty weird to me. Diego what folder is jcl-over-slf4j-1.5.2.jar in? Do you have another copy in shared tomcat libraries? Or together with tomcat own jars?
I tested including jcl-over-slf4j in both the webapp WEB-INF/lib dir and in global tomcat common/lib. Got the same error both times. The pattern is as follows: have a perfectly working app with logging working with slf4j + logback; then include jcl-over-slf4j jar and get the JNDI NameNotFoundException. Maybe I'm wrong, but I'm pretty sure this is related to tomcat using JCL internally for logging in the catalina engine, way before the webapp is ready. One question is if this problem would happen if the datasource was defined as global to all tomcat webapps (defined in the global context), instead of being a webapp-defined datasource. My guess is that it will work because that JNDI object will probably be defined and running before the webapps are initialized (but this is only a guess on the internal behaviour of tomcat!).
Cheers, Anton Tagunov logback user _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Regards. Diego.
Hi Diego, Diego> prepended by "java:comp/env", as this is the standard context for java Diego> objects and the JNDIConnectionSource does not prepend the searched values with it. Anton> Looks like a nice idea to me. Anton> Will not be backwards compatible but logback is not version 1 yet. Diego> In my company we have our own DataSourceLocator class that abstracts the Diego> JNDI lookup and automagically prepends all searched keys with Diego> "java:comp/env" but this is obviously custom behaviour. Diego> There are two options here: document the need for the prefix in the Diego> manual or add the prefix to all keys in the JNDIConnectionSource class. Diego> I'd suggest the former option as the best one Could you please create a Jira item for this? Don't worry, if it's deemed a bad idea the item shall be simply closed as 'WONT FIX'. Diego> Another thing I got problems with was slf4j's jcl-over-slf4j-1.5.2.jar. Diego> logback ... initialized too early when using jcl-over-slf4j, before tomcat Diego> makes the JNDI resources available to the web application Diego> ch.qos.logback.core.db.JNDIConnectionSource@67c1a6 - Error while getting Diego> data source javax.naming.NameNotFoundException: Diego> javax.naming.NameNotFoundException: 'comp' can't be found in this context Diego> at org.apache.naming.NamingContext.lookup(NamingContext.java:770) Diego> ... Diego> org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155) Diego> org.apache.commons.logging.LogFactory.getLog(LogFactory.java:704) Diego> org.apache.catalina.core.ContainerBase.getLogger(ContainerBase.java:381) Diego> ... Diego> org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149) Anton> Looks pretty weird to me. Diego what folder is jcl-over-slf4j-1.5.2.jar in? Anton> Do you have another copy in shared tomcat libraries? Or together with tomcat own jars? Diego> I tested including jcl-over-slf4j in both the webapp WEB-INF/lib dir and Diego> in global tomcat common/lib. Got the same error both times. Diego, could you please try this WITHOUT jcl-over-slf4j in common/lib? 99.99% probability that it's the root of the problem. Cheers, Anton
Since there has been some recent discussion of tomcat, slf4j, jcl-over-slf4j and logback combinations, this account of how we solved our problem may be useful to some.... or maybe someone has a better way. Our desires: - use a standard (within our organization) java logging implementation - have logging for each application be separately configurable but share a common syntax (so we wouldn't have to remember all different configuration details) - use the same logging implementation for tomcat - support existing applications that send throttled email alerts (log4j based) - we had some other desires but the above are important for this discussion Our solution: We used logback, slf4j, log4j-over-slf4j, and jcl-over-slf4j in combination with a custom logback context selector. More details: We ran into similar problems as others have mentioned. Once we included jcl-over-slf4j in tomcat, we had initialization problems. We tried the JNDI context selector but it didn't work. Basically, as tomcat is loading a web app, it attempts some logging (using jcl) before it sets up the jndi context. As soon as the first logging statement is run, logback will be initialized. Since it cant use any jndi information, it uses the default initialization process. This default initialization process is not very useful when you want to have a per application (and tomcat) logback configuration. We ended up writing a logback context loader that loads it's configuration based on classpath resources. Then we placed tomcat specific files in tomcat/server/lib and tomcat/server/classes (vs. tomcat/common). By placing in tomcat/server, web apps can't see the tomcat specific configs and jars. Each web application then placed it's logging jars and configuration files in their own WEB-INF. Benefits of this configuration: - tomcat and each web app can have their own logging configuration - each logback context can be managed separately via JMX Hope this helps someone. -casey
Hello Lucas, Many thanks for this post. I wish we had a wiki to keep track of this kind of contributions. Cheers, Lucas, Casey wrote:
Since there has been some recent discussion of tomcat, slf4j, jcl-over-slf4j and logback combinations, this account of how we solved our problem may be useful to some.... or maybe someone has a better way.
Our desires:
- use a standard (within our organization) java logging implementation
- have logging for each application be separately configurable but share a common syntax (so we wouldn't have to remember all different configuration details)
- use the same logging implementation for tomcat
- support existing applications that send throttled email alerts (log4j based)
- we had some other desires but the above are important for this discussion
Our solution:
We used logback, slf4j, log4j-over-slf4j, and jcl-over-slf4j in combination with a custom logback context selector.
More details:
We ran into similar problems as others have mentioned. Once we included jcl-over-slf4j in tomcat, we had initialization problems. We tried the JNDI context selector but it didn't work. Basically, as tomcat is loading a web app, it attempts some logging (using jcl) before it sets up the jndi context. As soon as the first logging statement is run, logback will be initialized. Since it cant use any jndi information, it uses the default initialization process. This default initialization process is not very useful when you want to have a per application (and tomcat) logback configuration.
We ended up writing a logback context loader that loads it's configuration based on classpath resources. Then we placed tomcat specific files in tomcat/server/lib and tomcat/server/classes (vs. tomcat/common). By placing in tomcat/server, web apps can't see the tomcat specific configs and jars. Each web application then placed it's logging jars and configuration files in their own WEB-INF. Benefits of this configuration:
- tomcat and each web app can have their own logging configuration
- each logback context can be managed separately via JMX
Hope this helps someone.
-casey
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- Ceki Gülcü QOS.ch is looking to hire talented developers located in Switzerland to work on cutting-edge software projects. If you think you are qualified, then please contact ceki@qos.ch.
participants (4)
-
Anton Tagunov -
Ceki Gulcu -
Diego Louzán -
Lucas, Casey