This is the 12th day of my participation in Gwen Challenge

The new features in Spring Boot2. x are also noticeable with the addition of Spring Framwork5 incorporates netty as a startup container to add asynchronous non-blocking mechanisms, support for http2.x, and significant performance improvements to the redis underlying framework. Of course, springboot2.x has improved the framework even further. When upgrading from BOOt1. x to boot2.x, you will inevitably encounter various problems. Here I summarize some of the common problems and puzzles most of you will encounter when upgrading the Boot framework. I hope I can help more partners with similar problems

The need to upgrade

Spring Boot 2.0 Migration Guide Before upgrading, we should pay attention to the following points:

  • Migrating to Spring Boot 2 will upgrade many dependencies, and you need to determine compatible versions before upgrading.
  • Custom configuration related changes. Such as the configuration etc.
  • Spring Boot 2.0 requires Java 8 or later. Java 6 and 7 are no longer supported. The Framework base is integrated with Spring Framework 5.0.
  • Following spring’s official instructions, we recommend upgrading to the latest GA in stages rather than all at once: first to 2.0, then 2.1.

  • Spring Boot now uses the CGLIB proxy by default, including support for AOP. If you need an interface-based proxy, you will need to set spring.aop.proxy-target-class to false.
  • If we use java-jar to follow the external configuration file after the boot command, then the parameters of the external configuration file need to be changed to spring.config.location in boot 1.x and changed to spring.config.location in boot2.x Spring. Config. Additional – the location.

  • In terms of web container interface calls, instead of providing a RestTemplate, you become a RestTemplateBuilder directly

And so on, the above new features are in the boot2.0 migration guide, I suggest you partners in the framework before the upgrade of the reference, can help us a lot.

2.x and 1.x Redis integration differences

In the x version, the default is to use the database database. 1. Jedis is used by default in the X version. Jedis and Lettuce are both Redis clients. Jedis is a direct connection mode, it is thread unsafe to share a Jedis instance between multiple threads. 3. If you want to use Jedis in a multi-threaded environment, you need to use connection pooling.

ConfigurationProperties prefix prefix hump naming problem

The configuration in our YML is hierarchical as follows

activityImage:
  onScreenTime: 7
Copy the code

Spring Boot 2.0 does not support camel nesting. It will trigger a InvalidConfigurationPropertyNameException: the name of the configuration properties’ * * * * * * * * ‘is invalid. Need to change in the code:

@ConfigurationProperties(prefix = "activity-image")

Copy the code

feign.optionals.OptionalDecoder

Feign. Optionals. OptionalDecoder information is missing, in boot2. X is cancelled spring – the cloud – openfeign – the core, And feign. Optionals. OptionalDecoder information in feign – java8 package, we need to introduce the spring – the cloud – starter – feign component packages, because in this component package contains the feign – java8 package information.

No qualifying bean of type ‘org. Springframework. Scheduling. Concurrent. ThreadPoolTaskScheduler

In boot1.x, we directly inject ThreadPoolTaskScheduler with @autoWired. However, we can programmatically new the ThreadPoolTaskScheduler directly. TaskScheduler scheduler scheduler scheduler scheduler scheduler scheduler

@Configuration
public class SchedulerConfig extends WebMvcConfigurerAdapter{    
    
    @Bean
    public TaskScheduler scheduledTaskExecutor(a) {
        ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();
        scheduler.setPoolSize(10);
        scheduler.setThreadNamePrefix("scheduled-thread-");
        returnscheduler; }}Copy the code

What if some method types change in JPA after the upgrade? Examples include Findone, findAll, etc

  • The findone method

The findone method input parameter is not a String type. The findone method return type is Optional. Here I give two effective solutions, we can refer to the following ways to solve it:

Student stu= Student stu= Student stu= Student stu=new Student();
        stu.setId("12345");
        Student student = studentRepository.findOne(Example.of(stu)).orElse(null); Spring Data Jpa supports method names defined in the Repository interface to define queries based on attributes of the entity class. studentRepository.findById(id).orElse(null)
Copy the code

These are two ways to solve the previous Findone JPA, but I prefer the second method, which can be used directly by the method name, which is the name of the object’s property, to perform precise queries, which is really nice.

  1. The.findall method



With regard to the findAll method, my personal feeling is that it’s generally not that different from relying on a lower version. The findAll method replaces the previous method of receiving a list argument with no arguments, but as we can see from the source code, we can pass a list and pass a bunch of ids to query. We can also use the findAllById method to replace the way we passed arguments in findAll. In addition, if we really want to use the original findAll method, we can also use JPA SQL method to solve the problem, such as the following case:

 @Query("SELECT t FROM Student t WHERE id IN (:ids)")
  List<Student> findAll(@Param("Ids") List<String> Ids);
Copy the code

This is my compatibility approach. After upgrading the framework, JPA is a bit more modified. If we are using a few common methods based on JpaRepository, we will need to change the business code to be compatible.