Jar loading order error causes spring-boot startup to fail #1871
Comments
|
我建议你使用AOP来处理A.jar重写B.jar的问题，最好不要两个具备相同类的jar包 UPDATE by @chanseokoh: Google Translate says "I suggest you use AOP to handle the problem of A.jar rewriting B.jar. It is best not to have two jars with the same class." |
|
I agree with what @luxingxiao said. I don't know about AOP, but I think it seems best to avoid having multiple JARs with same classes. This seems particularly true in this case where the class clash is not accidental but is to intentionally override the other class. Maybe you could consider shading (although I'm not saying shading is a good thing.) As a last resort, there is an ugly workaround that you prepend |
Thank you @chanseokoh . AOP means Aspect Oriented Programming . |
谢谢你的建议🙏。事实上，A和B两个jar都是项目中依赖的外部jar包，所以对于其中像覆盖这种不规范的操作我也无能为力。不过我也仔细看了下源码，覆写的A.jar不仅改变了原来B.jar中的代码逻辑，还变更了方法和类签名，所以我理解对于这种情况，是不是AOP也没有办法处理？ Thank you for your advice. In fact, both the A and B jars are external jars that depend on the project, so I can't do anything about covering such irregular operations. However, I also carefully looked at the source code. The overwritten A.jar not only changed the code logic in the original B.jar, but also changed the method and class signature, so I understand that for this situation, there is no way for AOP to handle it ? |
Thank you @chanseokoh. This is indeed a problem caused by an irregular operation. |
|
Setting the milestone just not to forget discussing. |
|
I think we should bump the priority on this. We can try to use the CLASSPATH env var, or maybe just fill the entrypoint with the correct values. We can allow users to |
|
Another project setup (originally from https://github.com/rvaidya/jib-conflict-test1) affected by the order of JAR dependencies in the
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>testpackage</groupId>
<artifactId>test-project</artifactId>
<version>0.0.1</version>
<dependencies>
<dependency>
<groupId>org.apache.tika</groupId>
<artifactId>tika-parsers</artifactId>
<version>1.24</version>
</dependency>
<dependency>
<groupId>org.jscience</groupId>
<artifactId>jscience</artifactId>
<version>4.3.1</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>3.0.0</version>
<configuration><mainClass>TestClass</mainClass></configuration>
</plugin>
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>2.5.2</version>
</plugin>
</plugins>
</build>
</project>
public class TestClass {
public static void main(String[] args) {
javax.measure.unit.NonSI.getInstance();
System.out.println("done");
}
}Running the project fails with Switching the order of Running locally with the Interestingly, the two dependencies don't have any common transitive dependencies. Dependency tree (click to expand):The issue is having different versions of the same classes in different JARs. For example,
public interface Volume extends Quantity {
public final static Unit<Volume> UNIT = SI.CUBIC_METRE;
}
public interface Volume extends Quantity<Volume> {}Therefore, the application behavior becomes non-deterministic and depends on whether <dependencies>
<dependency>
<groupId>org.apache.tika</groupId>
<artifactId>tika-parsers</artifactId>
<version>1.24</version>
<exclusions>
<exclusion>
<groupId>javax.measure</groupId>
<artifactId>unit-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.jscience</groupId>
<artifactId>jscience</artifactId>
<version>4.3.1</version>
</dependency>
</dependencies> |
|
@xiaopihai7256 @luxingxiao we've released Jib 2.7.0 which added a new configuration option ( instead of the default Expanding the dependency list can be useful in AppCDS too. Note that an expanded dependency list can become very long in practice, and we are not sure if there may be a potential issue due to a long command line ("argument list too long" or "command line is too long"). As with other Jib configurations, this option can also be set through the system property ( |
|
Will leave this issue open to add better support for Java 9+.
|
|
@xiaopihai7256 @luxingxiao Jib 3.1.1 is released, which creates two JVM argument files inside an image. One of them is the Java runtime classpath where all the dependencies are explicitly enumerated, which enables Jib to preseve the depending loading order by using this file for Java 9+. (For Java 8, you have to continue to set For those interested, see here for more details. |
Environment:
Description of the issue:
Sorry, my English is not good, but I will try to explain the problems I have encountered.
In my project, there are two jars with different names, we call A.jar and B.jar. A rewrites and overwrites a Class with the same name in B. In order to work properly, I introduce A in pom.xml in order higher than B, which works fine in Spring-boot's Fatjar.
But when I use Jib, B always loads before A, causing the coverage of the Class to not take effect, so when the application starts, the JDK prompts "XXXX method not found in XXX.class". finally, application start failed
Expected behavior:
A.jar can be loaded earlier than B.jar, just like working in Spring-boot's Fatjar.
Steps to reproduce:
mvn compile jib:build -Dregistry_url={my server ip}:4000 -Dregistry_username={username} -Dregistry_password={password} -Dimage_tag=v1.2.0-dev-2019072101 -DsendCredentialsOverHttp=truejib-maven-pluginConfiguration:Log output:
this is maven log:
when application running, this is error log of spring-boot:
Additional Information:
If you need additional information, I can always provide the party.
The text was updated successfully, but these errors were encountered: