concurrentlinkedhashmap dependency non-optional when declared as global JNDI Resource

[dcalde]

The pom.xml states that ConcurrentLinkedHashMap dependency is optional:

    <!-- ConcurrentLinkedHashMap dependency is used for JDBC statement caching only,
         that is disabled by default. If the client's application doesn't
         enable the statement caching, it may safely exclude this dependency. -->
    <dependency>
        <groupId>com.googlecode.concurrentlinkedhashmap</groupId>
        <artifactId>concurrentlinkedhashmap-lru</artifactId>
        <version>${concurrentlinkedhashmap-lru.version}</version>
    </dependency>

However when using vibur as a global JNDI resource in tomcat, it is required:

03-Dec-2015 11:34:15.544 SEVERE [main] org.apache.catalina.startup.Catalina.start The required Server component failed to start so Tomcat is unable to start.
 org.apache.catalina.LifecycleException: Failed to start component [StandardServer[8005]]
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
    at org.apache.catalina.startup.Catalina.start(Catalina.java:625)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:351)
    at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:485)
Caused by: java.lang.NoClassDefFoundError: com/googlecode/concurrentlinkedhashmap/EvictionListener
    at java.lang.Class.getDeclaredConstructors0(Native Method)
    at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
    at java.lang.Class.getConstructor0(Class.java:3075)
    at java.lang.Class.getConstructor(Class.java:1825)
    at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource.isBeanCompatible(MbeansDescriptorsIntrospectionSource.java:166)
    at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource.supportedType(MbeansDescriptorsIntrospectionSource.java:139)
    at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource.initMethods(MbeansDescriptorsIntrospectionSource.java:241)
    at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource.createManagedBean(MbeansDescriptorsIntrospectionSource.java:299)
    at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource.execute(MbeansDescriptorsIntrospectionSource.java:77)
    at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource.loadDescriptors(MbeansDescriptorsIntrospectionSource.java:70)
    at org.apache.tomcat.util.modeler.Registry.load(Registry.java:582)
    at org.apache.tomcat.util.modeler.Registry.findManagedBean(Registry.java:485)
    at org.apache.tomcat.util.modeler.Registry.registerComponent(Registry.java:614)
    at org.apache.catalina.core.NamingContextListener.addResource(NamingContextListener.java:1085)
    at org.apache.catalina.core.NamingContextListener.createNamingContext(NamingContextListener.java:663)
    at org.apache.catalina.core.NamingContextListener.lifecycleEvent(NamingContextListener.java:256)
    at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:95)
    at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
    at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:761)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    ... 7 more
Caused by: java.lang.ClassNotFoundException: com.googlecode.concurrentlinkedhashmap.EvictionListener
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 27 more

[simeonmalchev]

@dcalde, can you please confirm that statementCacheMaxSize was set to 0 when this happened? Also, which version of Vibur did you use?

[dcalde]

Yes, statementCacheMaxSize is not set at all, it uses the ViburDBCPConfig default of 0

[simeonmalchev]

@dcalde, are you able to provide us with any more information in order to replicate this issue, any configuration samples, the concrete Tomcat version in which this problem, as well as the concrete Vibur DBCP version which you're using?

In latest (5.0) version of Vibur DBCP all reference to com.googlecode.concurrentlinkedhashmap.* are isolated in StatementCache.java and the StatementyCache itself is not instantiated when statementCacheMaxSize is zero. For this reason, the problem which you're encountering is very strange, and that's why I'm asking for more details.

[dcalde]

This happened on my local dev machine. Windows 7 Pro, JDK 1.8.0_60, Tomcat 8.0.27, running inside Intellij IDEA 14.1.5. JmxRemoteLifecycleListener not enabled.

Simply adding concurrentlinkedhashmap-lru-1.4.2.jar to tomcat/lib fixed it.

[simeonmalchev]

Thanks for this info.

But are you using an of-maven-central Vibur DBCP version, like for example version 5.0 or version 4.0, or your own patched version of Vibur DBCP? If you're using a patched version, can you please send me the diff by email so that I can evaluate whether the diff has anything to do with the problem?

[dcalde]

I was using a patched version (1.0) but it was leaking connections (probably due to my changes... you might remember our discussion from ~1.5 years ago regarding testing connections on create) which is why we updated to the 5.0. Since updating to 5.0 and applying the changes as per the other JNDI bug, the pool is now working as expected.
Daniel

[simeonmalchev]

No worries, thanks Daniel.

I will close this issue as invalid and I'll fix the other JNDI issue.

Please let me know if you encounter any other issues.

[dcalde]

I don't think it is invalid, but I am happy to re-test once the other JNDI bug is resolved, so I replicate the issue with a non-patched version.

[simeonmalchev]

The other JNDI related issue #5 was just fixed on master.

As to this current issue #4, I guess my wording that the issue is invalid wasn't precise enough. I was trying to say that I'm not expecting #4 to be present in Vibur DBCP 5.0 or in the current master version. If possible, can you please retest the scenario in which you got the current issue #4 with version 5.0 or with build from master, and let me know whether the issue is present in any of those?

If yes, I'll dig it further.

[simeonmalchev]

@dcalde, my current opinion is that this issue here (#4) is not present in Vibur DBCP 5.0, and I would like to close it. I don't have sufficient resources to release bug fixing releases for older Vibur DBCP versions, and the solution for anyone who is experiencing this issue (#4) will be to migrate to version 5.0.