Table of contents
Problems encountered in introducing canal into microservice projects
java: warning: source release 11 requires target release 11
Problems encountered in introducing canal into microservice projects
Recently, I am working on a microservice project. In the project, canal will be used to monitor the business tables in the database. The problems encountered in the process of introducing canal: (If there is information, it is recommended to use the package in the information to copy directly, there is no relevant For the information, go to github to download it yourself)
Find the canal-related jar package provided by the project information, and then copy it to a path: use the mvn command to install this external jar package: (This is problematic, there is a process of stepping on the pit below, and another method )
Although this method can also install this dependency, there will be various problems. I have stepped on the pit and it took three hours to solve it. . . . . .
Don't install it like this, there will be a situation where there are dependencies but no specific dependencies : why this is the case, I don't know. . . . Anyway, from maven's cache to remote address, to maven's version issues have been considered, but the reason is still not found. . . . The reason for this is that I used mvn to install the jar package provided by the teacher, and then the following situation occurred, there are dependencies but no dependent packages, but the dependent packages are in the local warehouse. . . . . . . There are some dependencies that can be used, but an error will be reported when running. . .
//As for why,,, I don't know for the time being. . . . . . So in the end, I chose another method to introduce
mvn install:install-file -DgroupId=com.xpand -DartifactId=starter-canal -Dversion=0.0.1-SNAPSHOT -Dfile=D:\repo\starter-canal-0.0. 1-SNAPSHOT.jar -Dpackaging=jar-Dfile: Indicates the current location of the jar package, and the others are the same as maven coordinates.
Use the following method to install it (pro-test is effective), it can be used directly:
Copy the given resource directly to the corresponding package:
Then refresh the pom file in idea.
(1) Create engineering module xxx_canal, pom introduces dependencies
<!--canal相关-->
<dependency>
<groupId>com.xpand</groupId>
<artifactId>starter-canal</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
<!--rabbitMq相关-->
<dependency>
<groupId>org.springframework.amqp</groupId>
<artifactId>spring-rabbit</artifactId>
</dependency>(2) Create a package com.xxx.canal, and create a startup class under the package
@EnableCanalClient //标注为canal客户端
@SpringBootApplication
public class CanalApplication {
public static void main(String[] args) {
SpringApplication.run(CanalApplication.class,args);
}
}It can be used directly without error.
Exception in thread "main" java.lang.NoSuchMethodError: org.springframework.core.annotation.AnnotationAwareOrderComparator.sort(Ljava/util/List;)V
报错：Exception in thread "main" java.lang.NoSuchMethodError: org.springframework.core.annotation.AnnotationAwareOrderComparator.sort(Ljava/util/List;)V
Most of the errors reported are due to dependency problems ! ! For example, repeated dependencies lead to version conflicts , and then maven did not help you eliminate the repeated dependencies, because there may be different things in the two dependencies, so maven did not help you eliminate the version conflict dependencies, or your maven Something went wrong with the configuration. Let's talk about how to exclude manual version conflicts:
Find the conflict class of the error message: My error is that the AnnotationAwareOrderComparator class does not exist, and then conduct a global search for the AnnotationAwareOrderComparator class to see which packages have it:
Exception in thread "main" java.lang.NoSuchMethodError: org.springframework.core.annotation.AnnotationAwareOrderComparator.sort(Ljava/util/List;)V
at org.springframework.boot.SpringApplication.getSpringFactoriesInstances(SpringApplication.java:431)
at org.springframework.boot.SpringApplication.getSpringFactoriesInstances(SpringApplication.java:420)
at org.springframework.boot.SpringApplication.<init>(SpringApplication.java:268)
at org.springframework.boot.SpringApplication.<init>(SpringApplication.java:249)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1260)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1248)
at com.ydles.canal.CanalApplication.main(CanalApplication.java:16)
Double-click shift to enter the global search of idea:
Then refresh the pom.
java: warning: source release 11 requires target release 11
The reason for this problem is that the java version of the project conflicts with the jdk selection of the module, or even the jdk version configuration in the maven configuration conflicts with the jdk configuration required by the project module! ! !
Even sometimes you wonder if there is something wrong with the editor of idea: for example, you obviously modified the global jdk settings and language version settings of the project in idea, but as soon as you create a new maven project, and then run it, it will report java : WARNING: Source release 11 requires target release 11, are you wondering why this is? The answer is revealed below! ! !
Modify three positions first:
Then I happily started the project and found that there was no problem, but as soon as I created a new maven module, and then started the project of other modules, the java: Warning: source release version 11 requires target release version 11 this error. The reason for this is that you have configured other versions of jdk in the maven configuration file before, but you may have forgotten it after a long time, so you will be confused if this problem occurs in a new project!
So if you encounter this situation, you must go to the setting configuration file under the cnfg folder of maven to see the version of jdk configured in your own maven, and see that it is different from your own project . Just modify it to be the same. For example, if the project in your idea uses jdk8, then the configuration file using jdk8 should also be configured in the configuration file in maven.
The maven configuration of jdk11:
<profile>
<id>jdk-11</id>
<activation>
<activeByDefault>true</activeByDefault>
<jdk>11</jdk>
</activation>
<properties>
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
<maven.compiler.compilerVersion>11</maven.compiler.compilerVersion>
</properties>
</profile>Or the maven configuration of jdk8: (choose according to the jdk version in your actual project)
<profile>
<id>jdk1.8</id>
<activation>
<activeByDefault>true</activeByDefault>
<jdk>1.8</jdk>
</activation>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.compilerVersion>1.8</maven.compiler.compilerVersion>
</properties>
</profile>
The jdk version specified in the configuration file in maven is very critical, because every time you create a maven project or compile with maven, you will use the jdk version specified in the maven configuration file, so if the jdk here is different from the actual project The jdk is different, and it is easy to report version syntax errors.
The front-end and back-end separation projects can be started with debug, but no matter how you send the request, you can’t enter the debug
The scenario where I have this situation is: during the internship in the company, the leader only gave the gitlab address of the front-end and back-end codes of the project, and then after I pull the code to the local, the front-end and back-end projects can run normally, and the remote can also be accessed normally. The test library, but when we use debug to run java in the background, no matter how we send a request, we can’t enter the debug, but the project has obviously started with debug,,, I use the running background to click on the page to send a request Can't enter debug, use postman to simulate the request (with token), the request can be successful but can't enter debug,,,, so it is very confusing. . . . .
Later, I turned off the backend by myself, but clicking the button on the front end can still jump to the relevant page, which is interesting. After this operation, I finally found that in the project where the front and back ends are separated, the front end generally has a remote Proxy, finally in the front-end config file, we did see the address of the remote proxy, that is to say, the request we sent was actually forwarded to the configured remote address through the front-end remote proxy. . . .
The final solution is: change the location of the front-end configuration proxy address (the proxy address related to the project) to the local background project address (both the ip address and the port number must be changed). If you don't know which one to change specifically, you can ask the front end or seniors of your group, they must know. Finally restart the project, and then send a request, you can enter the debug.