0

I have two Spring MVC applications that share a commons.jar library. This library includes logback logging library (logback 1.2.3 and slf4j 1.7.25) and the logback.xml file.

Both wars include this line in their web.xml file:

<env-entry>
    <env-entry-name>applicationName</env-entry-name>
    <env-entry-type>java.lang.String</env-entry-type>
    <env-entry-value>nameOfApplicationA|nameOfApplicationB</env-entry-value>
</env-entry>

Each application generates its own log file including hostname, for example: HOST1-nameOfApplicationA.log. Logback configuration is as follows:

<insertFromJNDI env-entry-name="java:comp/env/applicationName" as="APP_NAME" />
<appender name="ROLLING_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>${LOG_PATH}/${HOSTNAME}-${APP_NAME}.log</file>
 ...
 </appender>

Everything was working OK (Spring MVC 4.3.7.RELEASE, Hibernate 4, C3P0 latest), but we decided to upgrade to Hibernate 5.2.10 and change to HikariCP 2.6.1. After that, logback was no longer able to resolve java:comp/env/applicationName:

ERROR in ch.qos.logback.classic.joran.action.InsertFromJNDIAction - [java:comp/env/applicationName] has null or empty value

Resulting in both applications using the same file name HOST1-APP_NAME_IS_UNDEFINED.log.

As we changed at the same time Hibernate and HikariCP we went back to C3P0 to check the root cause, and can confirm that the new version of Hibernate has nothing to do. The change was developed in its own branch so no other change seems to affect (anyway, when returning to C3P0 it works).

I've been doing some tracing in Hikari's and Logback's code but I'm not able to see anything. I'm stuck, no idea of what to look.

Plan B is insert in each war its own logback.xml but I would like to avoid it and understand the problem as it may affect other parts of the application.

Both wars are deployed together in an Apache Tomcat/8.0.38 server. Tried also 8.5.12. It also happens if only one of the wars is deployed alone.

Mike B
  • 101
  • 2
  • Please open this as an issue in the HikariCP issue tracker. While [this issue](http://stackoverflow.com/questions/33280425/logback-cant-find-all-applications-running-on-weblogic-using-insertfromjndi/33350961) is WebLogic, the cause may be the same -- two jars shading slf4j or logback. – brettw Apr 20 '17 at 06:02
  • The more I look at this, the more certain I am that it has nothing to do with HikariCP. HikariCP has nothing to do with JNDI. The *important* factor here is that HikariCP depends on ``slf4j`` and C3P0 does not. Which points to a similar, if not identical, cause as the issue mentioned in my previous comment. You need to grep all of the jars involved for "slf4j" -- Spring's jars, Tomcat's jars, third-party jars, your jars. The ``slf4j`` classes need to exist in *exactly* one of those jars, no more. If they are in more then one jar, you need to sort our your classpath. – brettw Apr 20 '17 at 06:27
  • I've been looking at the weblogic issue but I think it doesn't apply, as it fails even with only one war deployed. We're reviewing all `pom.xml` files searching for duplicated `slf4j` entries. – Mike B Apr 20 '17 at 11:04
  • Created issue in HikariCP issue tracker #873 https://github.com/brettwooldridge/HikariCP/issues/873 – Mike B Apr 20 '17 at 13:02

1 Answers1

0

Although I found no solution, @brettw identified the problem (see https://github.com/brettwooldridge/HikariCP/issues/873), and got a workaround.

It seems that because HikariCP depends on slf4j, and HikariCP is also being initialized and registered into JNDI, is that causing Logback to initialize before the <env-entry> entries have registered.

The test made was initalize Hikari datasource with "org.apache.naming.factory.BeanFactory" factory instead of "com.zaxxer.hikari.HikariJNDIFactory". This way it works correctly.

Mike B
  • 101
  • 2