日常踩坑

1.string.replace（“”，“xxx”）

此时结果为用xxx拆分字符串中所有字符。
eg:
	String a="ee";
    String b="x";
    String c="测试";
    System.out.println(a.replace("", b));
    System.out.println(c.replace("", b));
输出结果：
	替换a中空字符串后：xexex
	替换c中空字符串后：x测x试x
           

2.java -jar 启动报错：no main manifest attribute

maven打包问题，打的jar包里未指定main class
解决方案：项目pom文件里加maven插件依赖：
 <build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <executions>
                <execution>
                    <goals>
                        <goal>repackage</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>
           

3.mybatis反向生成，不同库有重名表时生成pojo字段异常

xml配置文件

情况1:

<jdbcConnection driverClass="com.mysql.cj.jdbc.Driver"
                    connectionURL="jdbc:mysql://localhost:3306/xxx"
                    userId="username"
                    password="password">
    </jdbcConnection>
    <table tableName="users"></table>
           

此时生成的pojo，匹配的是第一个查找到的名为“users"的表，不一定是配置库里的。

情况2:

<jdbcConnection driverClass="com.mysql.cj.jdbc.Driver"
                    connectionURL="jdbc:mysql://localhost:3306/xxx"
                    userId="username"
                    password="password">
                    <property name="nullCatalogMeansCurrent" value="true"/>
    </jdbcConnection>
    <table tableName="users"></table>
           

nullCatalogMeansCurrent表格未指定catalog时，选择当前配置的，此时生成的pojo匹配的则是当前配置库里的名为“users"的表。

情况3:

<jdbcConnection driverClass="com.mysql.cj.jdbc.Driver"
                    connectionURL="jdbc:mysql://localhost:3306/xxx"
                    userId="username"
                    password="password">
    </jdbcConnection>
    <table catalog="xxx"  tableName="users"></table>
           

catalog指定库名，此时生成的pojo匹配的则是指定库里的名为“users"的表。且生成pojo类上有注解@Table(“xxx…users”)

4.maven涉及jar包重复依赖（版本不一致时）时的pom原则

项目改动pom依赖导致启动报错，显示找不到HystrixDashboardStream类，排查后发现依赖的hystrix-core的jar包版本不对，pom中依赖声明的顺序和层级对最终生效的jar包版本有影响，总结原则如下：
1. 同一pom文件中重复依赖，后声明的生效
2. 不同pom文件中重复依赖，路径最短（）的生效
3. 不同pom文件中重复依赖，路径相同的情况下，先声明的生效