J'écrirai les points de correction lors de la migration de l'application de Spring Boot 1.5 (environ 7KL, partie serveur de SPA) vers Spring Boot 2.0. Un bon nombre de modifications ont été nécessaires, telles que la modification des packages de classe et la déconseillée.
Au début, je n'avais pas l'intention de définir Spring Boot sur 2.0, je voulais juste accéder à Elasticsearch 6, mais pour accéder à Elasticsearch 6, je dois augmenter spring-boot-starter-data-elasticsearch à 2.0 unités. Je n'avais pas d'autre choix que d'augmenter Spring Boot lui-même à 2.0.
Maven
L'application migrée cette fois dépend des bibliothèques suivantes.
pom.xml
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-cache</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-elasticsearch</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-mail</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.ldap</groupId>
<artifactId>spring-ldap-core</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.ldap</groupId>
<artifactId>spring-ldap-core-tiger</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-ldap</artifactId>
</dependency>
À l'origine, j'utilisais Spring IO platform, mais EOL est septembre 2019, et "spring-boot-starter-parent" Il est recommandé de l'utiliser ou d'importer les dépendances de spring-boot bom. " Suite à la recommandation, j'ai décidé de passer de la plate-forme Spring IO à spring-boot-starter-parent.
SpringBoot1.5
<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.spring.platform</groupId>
<artifactId>platform-bom</artifactId>
<version>Brussels-SR3</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
SpringBoot2.0
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.2.RELEASE</version>
</parent>
La hiérarchie des chemins de contexte a changé. Cela semble fonctionner tel quel, mais il est plus sûr de le changer.
SpringBoot1.5
server:
context-path: /sample
SpringBoot2.0
server:
servlet:
context-path: /sample
Puisque Spring Boot 2.0 est compatible Java 8, la classe Adapter, qui implémente l'interface vide, est obsolète et l'implémentation par défaut de la méthode a été ajoutée à l'interface elle-même. Par conséquent, la modification consiste à implémenter l'interface directement au lieu d'étendre l'adaptateur.
SpringBoot1.5
public class WebMvcConfig extends WebMvcConfigurerAdapter {
SpringBoot2.0
public class WebMvcConfig implements WebMvcConfigurer {
J'ai exclu SecurityAutoConfiguration, qui est une configuration automatique de la sécurité, afin de changer les paramètres de sécurité en fonction du profil, mais ce package SecurityAutoConfiguration a changé.
SpringBoot1.5
import org.springframework.boot.autoconfigure.security.SecurityAutoConfiguration;
@EnableAutoConfiguration(exclude = SecurityAutoConfiguration.class)
SpringBoot2.0
import org.springframework.boot.autoconfigure.security.servlet.SecurityAutoConfiguration;
@EnableAutoConfiguration(exclude = SecurityAutoConfiguration.class)
Il semble qu'il a été déplacé vers le package de servlet supplémentaire sous le package de sécurité.
J'utilisais ShaPasswordEncoder pour le cache interne, mais la classe elle-même a disparu. La structure de classe liée à PasswordEncoder a été revue. Parallèlement à cela, la classe ShaPasswordEncoder et la classe Md5PasswordEncoder qui utilisaient des algorithmes vulnérables ont disparu (l'algorithme lui-même semble rester, mais il est [obsolète]](https: //info.michael-simons. eu / 2018/01/13 / spring-security-5-new-password-storage-format /)).
À partir de Spring Boot 2.0, PasswordEncoder sera généré à l'aide de PasswordEncoderFactories.
SpringBoot1.5
MessageDigestPasswordEncoder encoder = new ShaPasswordEncoder(256);
return encoder.encodePassword(password);
SpringBoot2.0
PasswordEncoder encoder = PasswordEncoderFactories.createDelegatingPasswordEncoder();
return encoder.encode(password);
La méthode est également passée de encodePassword () à encode ().
La partie la plus difficile de ce correctif était la suivante (car il y en avait tellement ...). La méthode findOne () de CrudRepository a été renommée findById (), et la valeur de retour est désormais un type facultatif au lieu d'un type d'entité.
SpringBoot1.5
Employee employee = employeeRepository.findOne(employeeId);
SpringBoot2.0
Optional<Employee> employee = employeeRepository.findById(employeeId);
PageRequest new est obsolète. Utilisez plutôt ().
SpringBoot1.5
employeeRepository.findAll(specifications,
new PageRequest(page, size, new Sort(
Sort.Direction.fromString(sortDirection), sortColumn)));
SpringBoot2.0
employeeRepository.findAll(specifications,
PageRequest.of(page, size, new Sort(
Sort.Direction.fromString(sortDirection), sortColumn)));
Si vous changez PageRequest en of (), vous devez changer Sort en of () pour unifier le style.
SpringBoot2.0
employeeRepository.findAll(specifications,
PageRequest.of(page, size, Sort.of(
Sort.Direction.fromString(sortDirection), sortColumn)));
Avec Java 8 et l'ajout d'une implémentation par défaut à l'interface Specification, l'utilisation directe de la classe Specifications qui implémente l'interface Specification est obsolète. (Bien que l'implémentation par défaut de l'interface Specification utilise la classe Specifications.)
SpringBoot1.5
employeeRepository.findAll(
Specifications.where((root, query, cb) -> cb.equal(property, value)));
SpringBoot2.0
employeeRepository.findAll(
Specification.where((root, query, cb) -> cb.equal(property, value)));
Il y a également eu un changement en raison de la mise à niveau de la version Hibernate vers la version 5.2.17 avec Spring Boot 2.0.
J'ai utilisé la classe ExplicitParameterInfo lorsque je voulais spécifier explicitement NULL en utilisant NativeQuery d'Hibernate, mais le package de cette classe est de ʻorg.hibernate.jpa.criteria.compile.ExplicitParameterInfo à ʻorg.hibernate.query Changé en .criteria.internal.compile.ExplicitParameterInfo.
** Addendum / Mise à jour du 12/07/2018 ** Dans le cas de PostgreSQL 10, au moins ExplicitParameterInfo ne peut plus être spécifié lors de la spécification de NULL. Lorsque j'utilise ExplicitParameterInfo, j'obtiens une erreur comme "ʻorg.postgresql.util.PSQLException: ERREUR: l'opérateur n'existe pas: text = by tea`". Par conséquent, si vous souhaitez spécifier un type NULL, utilisez TypedParameterValue au lieu de ExplicitParameterInfo.
SpringBoot1.5
import org.hibernate.jpa.criteria.compile.ExplicitParameterInfo;
//Omission
Query query = entityManager.createNativeQuery(query);
query.setParameter(new ExplicitParameterInfo<>("employeeName", null, String.class), null);
List<Employee> employeeList = query.getResultList();
SpringBoot2.0
import org.hibernate.jpa.TypedParameterValue;
import org.hibernate.type.StringType;
//Omission
Query query = entityManager.createNativeQuery(query);
query.setParameter("employeeName", new TypedParameterValue(new StringType(), null));
List<Employee> employeeList = query.getResultList();
Dans cette application, il y avait une classe d'implémentation de UserType qui convertit entre la colonne JSONB de PostgreSQL et la chaîne de Java. Dans Spring Boot 2.0 (Hibernate 5.2.17), la classe SessionImplementor pour l'argument nullSafeGet / nullSafeSet a disparu et est maintenant un SharedSessionContractImplementor.
SpringBoot1.5
public class PostgresJsonType implements UserType {
@Override
public Object nullSafeGet(ResultSet rs, String[] names,
SessionImplementor session, Object owner)
throws HibernateException, SQLException {
//・ ・ ・
}
public void nullSafeSet(PreparedStatement st, Object value,
int index, SessionImplementor session)
throws HibernateException, SQLException {
//・ ・ ・
}
//・ ・ ・
}
SpringBoot2.0
public class PostgresJsonType implements UserType {
@Override
public Object nullSafeGet(ResultSet rs, String[] names,
SharedSessionContractImplementor session, Object owner)
throws HibernateException, SQLException {
//・ ・ ・
}
public void nullSafeSet(PreparedStatement st, Object value,
int index, SharedSessionContractImplementor session)
throws HibernateException, SQLException {
//・ ・ ・
}
//・ ・ ・
}
Cela a été à l'origine mal implémenté, mais dans application.yml
app:
function:
message-type:
AAA: xxx
BBB: yyy
Lors de la liaison de valeurs dans les propriétés de configuration
@ConfigurationProperties(prefix = "app.function.messageType")
Il était possible de lier en se référant à l'étui de la chaîne avec l'étui camel.
Dans Spring Boot 2.0, la vérification devient stricte, et si elle est dans l'état ci-dessus, une erreur se produira. (Il est naturel qu'une erreur se produise.)
Écrivons correctement un cas de chaîne selon la définition. ..
@ConfigurationProperties(prefix = "app.function.message-type")
Il y a de nombreux changements que je n'ai pas rencontrés dans cette migration. Il y a Spring Boot 2.0 Migration Guide sur le site officiel, veuillez donc vous y référer également. ..
Recommended Posts