Nosuchmethod troubleshooting and follow-up

Document directory

• Problem locating:
• Subsequent prevention:

Problem: nosuchmethod is reported when the application is released. This problem does not occur during the test environment. Generally, this problem occurs because two identical classes exist in the classpath corresponding to the same classloader (that is, the package and classname are the same, and the specific classloader mechanism is not mentioned here ), so follow this idea to find the problem. Problem locating: After troubleshooting, the problem is indeed the case above. The application uses Maven for jar package management, because the check is not careful enough when the third-party library is introduced into the second-party library, the following situation occurs:

• Developer A: oldjar1.0 -----> rename ----> Testa
• Developer B: oldjar1.1 -----> rename ----> testb

Classa exists in both oldjar 1.0 and 1.1, and classa in version 1.1 has a methoda method than in Version 1.0. The application depends on two packages in Testa and testb at the same time. Because the names are different (although the content is the same), MAVEN will not process the packages during arbitration, in this way, two classes with the same name and different method content exist in the Lib. When the classa (with methoda) classa (without methoda) application is started, because the Lib corresponds to a classloader for loading, It is random to load the classa. If it happens to be loaded to classa (without methoda) and methoda is used in the application, nosuchmethod will prevent it later: this problem is a runtime error and is hard to detect, if it appears, it is destructive, so you need to find some ways to prevent it. 1. Write a script to check duplicate classes in the application. The following is a small script written by myself, which can be implemented. (Shell is not very easy to write, it is poorly written, and is being optimized)

#! /Bin/bash ### recursive proportional folder. output Function list_alldir () {for file in $1/* doif [-d $ file]; thenlist_alldir $ file # here call else recursively ### filter. if ['echo $ file | sed-n '/. *\. class/P']; then ### extract package + classnameshortname = 'echo $ file | sed-E's /. *\. jar // g'' ### Package content fullname = $ shortname ">" $ file ### output echo $ fullname >>>$ class_info_file1_idone ## execute command directory run_dir = 'pwd' # war package full path war_path = $ 1if [! -F $ war_path]; thenecho "Enter the full path name of the War package! "Exitfi # Name of the local war package war_name = guangeitemp. war # temporary path for script processing temp_dir = $ run_dir/guanfeitemp # decompressed lib path lib_dir = $ temp_dir/WEB-INF/lib # obtain the file stored after the class file name class_info_file = $ run_dir/classnamefile # final result file dest_file = $ run_dir/destfile # create temporary processing folder mkdir $ temp_dircd $ temp_dir # copy the war package to the temporary directory CP $ war_path $ war_name # decompress the war package 'jar XF $ war_name '# To the lib directory CD $ lib_dirtouch $ class_info_file # traverse the jar package under Lib, find the class file and record it for jarname in 'LS-1 | awk '{print }''; doecho $ jarname # create a temporary decompression directory for the jar package mkdir d $ jarnammcm d $ jarname # decompress the jar package CP $ lib_dir/$ jarname. 'jar XF $ jarname' RM $ jarname # traverse list_alldir 'pwd' # Return the parent directory CD .. donetouch $ dest_file # Cat $ class_info_file | awk-F ">" '{print $1 | "Sort | uniq-cd"}'> $ dest_file # Clear the temporary file directory if [-d $ temp_dir]; thenrm-RF $ temp_dirfi

2. Write a Maven plug-in and check all the duplicates. The workload is not large. If you have time, add the solution.