A little workaround for version conflicts, how do I search for conflicting methods in all jar files?

MAVEN is a great project management tool, and you can easily define a reference to use a library that someone else has written. and Maven can easily mate with Jenkins, making it easier to package your deployment.

But also because of this, we become more fool, so that sometimes we forget some primitive basic methods, of course, this is not the purpose of this article, the purpose of this article is how to solve some of the conflicts caused by Maven.

Problem 1:jenkins packaging failed, so I can't install the code into the test environment, what should I do?

A: In general, we will do some two development based on Jenkins to suit the needs of the company, or to optimize some of the modified things. But since Jenkins is still more complex, sometimes it's hard to understand how it works, leading to problems that can't be packaged. Of course, my side of the problem is generally due to Jenkins's caching mechanism caused by the problem, so, in my local can be packaged code, put on Jenkins on the death of the package, because I rely on a jar package, because it was Jenkins cache an old version of the package, There's nothing new inside of me that causes the package to fail, and it seems that the cache problem cannot be resolved in a short time.

So, after I hit the war package with the Local IDE tool, I uploaded it to the Tomcat directory on the server, waiting for the new code to be restarted after Tomcat auto-deployment, bypassing the Jenkins failure.

For jar packages, it is more convenient to generate the jar package directly locally, then replace the corresponding package on the server and restart the service.

In short, the solution here is that when the tool is out of the question, we can no longer rely on the tool and go back to the original state to solve the problem.

Question 2: When we run the code (WAR/JAR), reported that a method is not found, that is: Java.lang.NoSuchMethodError:, carefully review the code, actually there is this method, how to troubleshoot?

A: For this issue, it is generally due to the introduction of multiple jar packages of the same functionality, and the package path is exactly the same, and when the ClassLoader loads, it may be loaded into a class that you do not want to load, resulting in the absence of the method.

The solution is to delete the references that are not your own, thus reaching the class that uses your own intent. In Maven, it appears to exclude a dependency, such as:

       <Dependency>            <groupId>Com.xx.activity</groupId>            <Artifactid>Abc</Artifactid>            <version>2.0.13-snapshot</version>            <classifier>Dubbo</classifier>            <Exclusions>                <exclusion>                    <groupId>Com.meidusa.venus</groupId>                    <Artifactid>Venus-backend</Artifactid>                </exclusion>            </Exclusions>        </Dependency>

However, there is a problem, that is, how to find the reference to which package, the resulting conflict? Because you see from the local code, there is no exception.

We can directly search the entire package of references, and unlock the code, to see the conflicting classes (conflict methods are difficult to find out), of course, is directly on the server to look up.

Find. -name ' *.jar '-exec JAR-TVF {} \; | grep EE   # identifies all the jar packages, extracts the list of files, and then searches for conflicting class names

If there are two identical results found, then it is a conflict, resolve the conflict.

Of course, if you introduce a few jar files, or if you have a basic direction to suspect which package is conflicting, then directly download the package, compiled with the Anti-compilation tool (such as Jd-gui), to see its internal situation, it will be at a glance.

Question 3: found that Tomcat start abnormally fast, and a lot of loading process is not, directly started, in fact, the services should not exist, how to troubleshoot?

A: This problem is not a clue, the solution is basically by luck. Here tomcat looks normal, but in fact a lot of things are not done and not loaded. From another point of view, the load is interrupted. The most troublesome thing is that none of the information in the log is given. You can generally start from the changes in the code to begin troubleshooting, a period of code to restore the main method of troubleshooting.

One of the key issues is that you refer to a JDK version of the jar with a higher operating environment than your own, according to the JVM loading principle, it will first check the class file version number, if it is more than the version you can load, then it directly refused to load, It does not check whether the class file references some of the features that you do not recognize. If the JVM does not load the class, then you will not be able to follow the process.

If the problem is caused by the jar package version, then the problem is solved.  1. Either the student who is calling you to provide the jar pack will drop the JDK version of the package into the version you need. 2. Upgrade your JVM runtime environment and upgrade the JDK, of course this risk may be, be careful.

Above, is a little bit of troubleshooting experience, chat to comfort. I would also like to point out a direction for students with similar problems.

When we encounter problems, we often do, a problem, may not be able to solve a few days down, but to really solve the time, found in fact very simple. Then, maybe next time, go on!

A bit of a workaround for versioning conflicts, how do I search for conflicting methods in all jar files?