# Elasticsearch jar hell when writing integration tests **URL:** https://discuss.elastic.co/t/elasticsearch-jar-hell-when-writing-integration-tests/64273 **Category:** Elasticsearch **Created:** [October 28, 2016, 10:53am UTC](https://discuss.elastic.co/t/elasticsearch-jar-hell-when-writing-integration-tests/64273 "2016-10-28T10:53:10Z") **Posts on this page:** 7 **Page:** 1
### Author: ![escay](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/escay/32/12344_2.png) [@escay](https://discuss.elastic.co/u/escay) #### Post date: [October 28, 2016, 10:53am UTC](https://discuss.elastic.co/t/elasticsearch-jar-hell-when-writing-integration-tests/64273/1 "2016-10-28T10:53:10Z")
Elasticsearch 5 forces me to use the ESIntegTestCase instead of starting my own Node for my integration tests from Java because NodeBuilder is not available anymore. So I try to do things the right way using: > **[integration tests | Elasticsearch Guide \[5.0\] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/5.0/integration-tests.html)** My product uses a large number of dependencies that are also used by Elasticsearch. For example apache.commons codec and logging and [Netty.io](http://Netty.io). Due to the strict nature of ESIntegTestCase it is required to use a clean classpath in the integration tests. There is the jar hell checker to check this. I understand the purpose of this check and I have read multiple issues and discussions about it. But it makes writing an integration test really impossible. Example: I depend on netty-all-final4.1.5.jar and elasticsearch depends on the same Netty jars, but not on the final distribution but on the separate jars. To get the integration test working I must either rewrite my code to depend on the separate [netty.io](http://netty.io) jars (netty-buffer, netty-common, netty-codec, etcetera) and use the same approach as elasticsearch uses. Or I have to exclude a number of dependencies manually in my integration test dependencies. And next time elasticsearch upgrades and uses some other approach I have to redo this error prone work again. Is there a trick to circumvent the jar hell checker? I'm not writing ES integration tests, I'm writing integration tests for my own product, which has to talk against ES. ``` java.lang.RuntimeException: found jar hell in test classpath at org.elasticsearch.bootstrap.BootstrapForTesting.(BootstrapForTesting.java:90) at org.elasticsearch.test.ESTestCase.(ESTestCase.java:138) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:585) Caused by: java.lang.IllegalStateException: jar hell! class: io.netty.util.HashingStrategy$1 jar1: F:\maven\repo\io\netty\netty-common\4.1.5.Final\netty-common-4.1.5.Final.jar jar2: F:\maven\repo\io\netty\netty-all\4.1.5.Final\netty-all-4.1.5.Final.jar at org.elasticsearch.bootstrap.JarHell.checkClass(JarHell.java:291) at org.elasticsearch.bootstrap.JarHell.checkJarHell(JarHell.java:187) at org.elasticsearch.bootstrap.JarHell.checkJarHell(JarHell.java:88) at org.elasticsearch.bootstrap.BootstrapForTesting.(BootstrapForTesting.java:88) ... 4 more ``` References to jar hell: > [@Trivial NodeBuilder Java code resulting in "jar hell" error](https://discuss.elastic.co/t/trivial-nodebuilder-java-code-resulting-in-jar-hell-error/34731): > > This code package threepieces.esonly; import org.elasticsearch.client.Client; import org.elasticsearch.common.settings.Settings; import org.elasticsearch.node.NodeBuilder; public class TrivialNode { public static void main(String[] argsIgnored) { Settings settings = Settings.settingsBuilder() .put("path.home", "/Applications/elasticsearch-2.0.0/") .put("cluster.name", "epsteinj-elasticsearch-local") .put("http.enabled", true) … > [@"Jar Hell" in Eclipse project that requires JBoss modules jars](https://discuss.elastic.co/t/jar-hell-in-eclipse-project-that-requires-jboss-modules-jars/41337): > > I'm having a problem similar to [Trivial NodeBuilder Java code resulting in "jar hell" error](https://discuss.elastic.co/t/trivial-nodebuilder-java-code-resulting-in-jar-hell-error/34731/3) ... except that I'm getting conflicts between jars loaded from the eclipse project libraries and libraries in our Jboss server installation. We have code that accomplishes various "tasks", but running standalone in a faked-up server environment (we load the Jboss libraries, and hand-create sessions, etc. for database connectivity, etc. This is all run from within Eclipse. No other library we're using … > [@ElasticSearch 2.0 java api JarHell problems](https://discuss.elastic.co/t/elasticsearch-2-0-java-api-jarhell-problems/34776): > > Hello everybody, I'm trying to migrate from elasticsearch 1.6.0 to 2.0.0 using the Java API. The tests were passing with 1.60. However, after I made the tests compile with 2.0.0 my tests are failing when running them locally due to various exceptions generated by JarHell. The question is, can I disable the JarHell check for local testing? Thanks! > > > When I try to run gradle integration tests to test a plugin by unpacking the zip…, the jar hell detection is unable to recognize the same jar on the class path at two (or more) different locations. > > I assume this is not intended. It would make gradle classpath setups (maybe other build tools too) to compile and test ES plugins "in-place" very difficult to specify. > > My suggestion is to skip jar URLs that point to a jar with a checksum of a jar that has been already checked. > > Example: > > \`\`\` > Caused by: java.lang.IllegalStateException: jar hell! > class: org.xbib.elasticsearch.http.HttpModule$\_configure\_closure1 > jar1: /Users/joerg/.gradle/caches/modules-2/files-2.1/org.xbib.elasticsearch.plugin/elasticsearch-webapp/2.0.0-beta1.0/c735bc9b3e05b37a2d553ddda7d76fefc5e817e5/elasticsearch-webapp-2.0.0-beta1.0.jar > jar2: /Users/joerg/Projects/github/jprante/elasticsearch-webapp-example/plugins/webapp/elasticsearch-webapp-2.0.0-beta1.0.jar > at org.elasticsearch.bootstrap.JarHell.checkClass(JarHell.java:210) > at org.elasticsearch.bootstrap.JarHell.checkJarHell(JarHell.java:128) > at org.elasticsearch.plugins.PluginsService.loadBundles(PluginsService.java:346) > ... 52 more > \`\`\` > > \`\`\` > shasum /Users/joerg/.gradle/caches/modules-2/files-2.1/org.xbib.elasticsearch.plugin/elasticsearch-webapp/2.0.0-beta1.0/c735bc9b3e05b37a2d553ddda7d76fefc5e817e5/elasticsearch-webapp-2.0.0-beta1.0.jar > c735bc9b3e05b37a2d553ddda7d76fefc5e817e5 /Users/joerg/.gradle/caches/modules-2/files-2.1/org.xbib.elasticsearch.plugin/elasticsearch-webapp/2.0.0-beta1.0/c735bc9b3e05b37a2d553ddda7d76fefc5e817e5/elasticsearch-webapp-2.0.0-beta1.0.jar > \`\`\` > > \`\`\` > shasum /Users/joerg/Projects/github/jprante/elasticsearch-webapp-example/plugins/webapp/elasticsearch-webapp-2.0.0-beta1.0.jar > c735bc9b3e05b37a2d553ddda7d76fefc5e817e5 /Users/joerg/Projects/github/jprante/elasticsearch-webapp-example/plugins/webapp/elasticsearch-webapp-2.0.0-beta1.0.jar > \`\`\` ---
### Author: ![escay](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/escay/32/12344_2.png) [@escay](https://discuss.elastic.co/u/escay) #### Post date: [October 28, 2016, 11:08am UTC](https://discuss.elastic.co/t/elasticsearch-jar-hell-when-writing-integration-tests/64273/2 "2016-10-28T11:08:14Z")
I found some more related information, and perhaps a solution: > > > This change moves the JarHell check under the test.security.manager guard > such t…hat users that have to opt out of JarHell for testing can do so by disabling > security. It will all users to use our test framework but when doing so the parameter > \`-Dtests.security.manager=false\` will signal how serious it is to opt out of this check > > Relates to #11932 > > > This relates to #16042 where we agreed on adding an opt-out on 2.2 for test > to d…isable jarhell checks in the BootstrapForTesting.java - for other branches we > will use different solutions. > > > Note its imperfect, there is currently some intentional "hell" done by ES: > \- spe…cifying elasticsearch.jar twice, in order to override a joda-time class > \- the overriding of said joda-time class > \- some clashes with log4j/log4j-extras > > But I removed all the jar hell in the test classpath and so on. > > Closes #11926 > > > Currently, JarHell checks the system classloader to find issues with jar collisi…ons. > > In order to support OSGi environments for \*\*testing\*\* embedded nodes, it's effectively a requirement that the parent classloader be checked instead. > > Pros: > \- The ability to embed ES into an OSGi environment, generally for testing capabilities in integration tests. > > Cons: > \- We currently do not support OSGi environments, which is why we do not test against them. Doing this type of check explicitly > \- Embedding nodes is not a recommended or supported in any environment. > \- This introduces the potential for unexpected issues "just" for the sake of supporting OSGi. > \- Supporting Java 9's jigsaw modularity may require different semantics. should it now be possible in ES 5.0 to disable the check by using -Dtests.jarhell.check=false ? It seems like the the "tests.jarhell.check" setting never made it to 5.0, only to 2.2 and 2.3 branches. > No if statement around the JarHell check: > ``` > // check for jar hell > try { > JarHell.checkJarHell(); > } catch (Exception e) { > throw new RuntimeException("found jar hell in test classpath", e); > } > > ``` Could anyone confirm this? ---
### Author: ![dantuff](https://avatars.discourse-cdn.com/v4/letter/d/e79b87/32.png) [@dantuff](https://discuss.elastic.co/u/dantuff) #### Post date: [January 24, 2017, 2:13pm UTC](https://discuss.elastic.co/t/elasticsearch-jar-hell-when-writing-integration-tests/64273/3 "2017-01-24T14:13:18Z")
Hi @escay We have the same issue as you. We were using the NodeBuilder to run our integration tests against our Search API which is a Spring Boot application. Since the upgrade to Elasticsearch 5 we can no longer use this method. I'm going to switch to using the ESIntegTestCase instead, but did you find a clean way to resolve the Jar Hell issues? Thanks, Dan ---
### Author: ![escay](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/escay/32/12344_2.png) [@escay](https://discuss.elastic.co/u/escay) #### Post date: [January 24, 2017, 6:24pm UTC](https://discuss.elastic.co/t/elasticsearch-jar-hell-when-writing-integration-tests/64273/4 "2017-01-24T18:24:02Z")
I tried to solve all dependency problems, but failed due to log4j version 1 versus log4j2 issues. We went back to ES version 2. The maven plugin to start ES 5 would be my next try. The plugin is supporting ES 5 in the meantime. ---
### Author: ![escay](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/escay/32/12344_2.png) [@escay](https://discuss.elastic.co/u/escay) #### Post date: [January 24, 2017, 6:33pm UTC](https://discuss.elastic.co/t/elasticsearch-jar-hell-when-writing-integration-tests/64273/5 "2017-01-24T18:33:27Z")
See > for the support in the maven plugin. This should allow you to start ES 5 for your integration tests. ---
### Author: ![dantuff](https://avatars.discourse-cdn.com/v4/letter/d/e79b87/32.png) [@dantuff](https://discuss.elastic.co/u/dantuff) #### Post date: [January 26, 2017, 1:34pm UTC](https://discuss.elastic.co/t/elasticsearch-jar-hell-when-writing-integration-tests/64273/6 "2017-01-26T13:34:46Z")
@escay The Elasticsearch maven plugin works nicely. Thanks for the heads up. ---
### Author: ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system) #### Post date: [July 5, 2017, 10:03pm UTC](https://discuss.elastic.co/t/elasticsearch-jar-hell-when-writing-integration-tests/64273/7 "2017-07-05T22:03:51Z")