escay
October 28, 2016, 11:08am
2
I found some more related information, and perhaps a solution:
elastic:master ← s1monw:check_jarhell_as_part_of_security
opened 06:52PM - 17 Jan 16 UTC
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
elastic:2.2 ← s1monw:disable_jarhell_on_2_2
opened 11:37AM - 22 Jan 16 UTC
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.
elastic:master ← rmuir:jarhell
opened 03:18AM - 30 Jun 15 UTC
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
opened 11:14PM - 18 Feb 16 UTC
closed 10:03PM - 30 Aug 16 UTC
feedback_needed
:Core/Infra/Core
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.
/*
* Licensed to Elasticsearch under one or more contributor
* license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright
* ownership. Elasticsearch licenses this file to you under
* the Apache License, Version 2.0 (the "License"); you may
* not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/
package org.elasticsearch.bootstrap;
show original
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?