TOC

O que há de novo no Spring Boot 2?

O que há de novo no Spring Boot 2?

1. Visão geral

O Spring Boot traz uma abordagem opinativa para o ecossistema do Spring. Lançado pela primeira vez em meados de 2014. O Spring Boot passou por muito desenvolvimento e aprimoramento. Hoje, sua versão 2.0 está se preparando para lançamento no início de 2018.

Existem diferentes áreas em que essa biblioteca popular tenta nos ajudar:

  • Gerenciamento de dependências. Através de iniciantes e várias integrações de gerenciador de pacotes

  • Configuração automática. Tentando minimizar a quantidade de configuração que um aplicativo Spring requer para se preparar e favorecer a convenção sobre a configuração

  • Recursos prontos para produção. ComoActuator, melhor registro, monitoramento, métricas ou integração com vários PAAS

  • Experiência de desenvolvimento aprimorada. Com vários utilitários de teste ou um loop de feedback melhor usandospring-boot-devtools

Neste artigo, vamos explorar algumas mudanças e recursos planejados para o Spring Boot 2.0. Também descreveremos como essas mudanças podem nos ajudar a nos tornarmos mais produtivos.

2. Dependências

2.1. Java Baseline

Spring Boot 2.x will no longer support Java 7 and below, sendo Java 8 o requisito mínimo.

Também é a primeira versão a oferecer suporte ao Java 9. Não há planos para oferecer suporte ao Java 9 na ramificação 1.x. Isso significaif you want to use the latest Java release and take advantage of this framework, Spring Boot 2.x is your only option.

2.2. Lista de materiais

A cada nova versão do Spring Boot, as versões de várias dependências do ecossistema Java são atualizadas. Isso é definido em Bootbill of materials aka BOM.

Na 2.x, isso não é exceção. Não faz sentido listá-los, mas podemos dar uma olhada emspring-boot-dependencies.pom para ver quais versões estão sendo usadas em um determinado momento.

Alguns destaques sobre as versões mínimas necessárias:

  • A versão mínima suportada do Tomcat é 8.5

  • A versão mínima suportada do Hibernate é 5.2

  • A versão mínima suportada da Gradle é 3,4

2.3. Plug-in do Gradle

O plug-in Gradle passou por grandes melhorias e algumas mudanças importantes.

To create fat jars, bootRepackage Gradle’s task gets replaced with bootJar and bootWar para construir potes e guerras respectivamente.

Se quiséssemos executar nossos aplicativos com o plugin Gradle, em 1.x, poderíamos executargradle bootRun.In 2.x bootRun extends Gradle’s JavaExec.. Isso significa que é mais fácil para nós configurá-lo aplicando a mesma configuração que normalmente usamos em tarefas clássicas deJavaExec.

Às vezes, nos encontramos desejando tirar proveito do BOM do Boot de Primavera. Mas às vezes não queremos construir um aplicativo de inicialização completo ou reembalá-lo.

Nesse sentido, é interessante saber queSpring Boot 2.x will no longer apply the dependency management plugin by default.

Se quisermos o gerenciamento de dependências do Spring Boot, devemos adicionar: 

apply plugin: 'io.spring.dependency-management'

Isso nos dá maior flexibilidade com menos configuração no cenário mencionado acima.

3. Autoconfiguração

3.1. Segurança

Na versão 2.x, a configuração de segurança é dramaticamente simplificada. By default, everything is secured, including static resources and Actuator endpoints.

Depois que o usuário configurar explicitamente a segurança, os padrões do Spring Boot deixarão de ser afetados. O usuário pode configurar todas as regras de acesso em um único local.

Isso nos impedirá de ter problemas com pedidos deWebSecurityConfigurerAdapter. Esses problemas costumavam ocorrer geralmente ao configurar as regras de segurança do atuador e do aplicativo de maneira personalizada.

Vamos dar uma olhada em um snippet de segurança simples que combina regras do atuador e do aplicativo: 

http.authorizeRequests()
  .requestMatchers(EndpointRequest.to("health"))
    .permitAll() // Actuator rules per endpoint
  .requestMatchers(EndpointRequest.toAnyEndpoint())
    .hasRole("admin") // Actuator general rules
  .requestMatchers(PathRequest.toStaticResources().atCommonLocations())
    .permitAll() // Static resource security
  .antMatchers("/**")
    .hasRole("user") // Application security rules
  // ...

3.2. Suporte Reativo

O Spring Boot 2 traz um conjunto de novos starters para diferentes módulos reativos. Alguns exemplos são WebFlux e as contrapartes reativas para MongoDB, Cassandra ou Redis.

Também existem utilitários de teste para o WebFlux. Em particular, podemos tirar vantagem de@WebFluxTest.. Isso se comporta de maneira semelhante aos@WebMvcTest mais antigos originalmente introduzidos como parte dos váriosslices de teste em 1.4.0.

4. Recursos prontos para produção

O Spring Boot traz algumas ferramentas úteis que nos permitem criar aplicativos prontos para produção. Entre outras coisas, podemos tirar proveito do Spring Boot Actuator.

O atuador contém várias ferramentas para simplificar o monitoramento, rastreamento e introspecção geral de aplicativos. Mais detalhes sobre o atuador podem ser encontrados em nossoprevious article.

With its 2 version actuator has been through major improvements. Esta iteração enfoca a simplificação da personalização. Ele também suporta outras tecnologias da web, incluindo o novo módulo reativo.

4.1. Suporte de Tecnologia

In Spring Boot 1.x only Spring-MVC was supported for actuator endpoints. In 2.x, however, it became independent and pluggable. Spring boot agora traz suporte pronto para uso para WebFlux, Jersey e Spring-MVC.

Como antes, o JMX continua sendo uma opção e pode ser ativado ou desativado através da configuração.

4.2. Criação de endpoints personalizados

A nova infraestrutura de atuadores é independente de tecnologia. Por isso, o modelo de desenvolvimento foi redesenhado do zero.

O novo modelo também traz maior flexibilidade e expressividade.

Vamos ver como criar um ponto finalFruits para o atuador: 

@Endpoint(id = "fruits")
public class FruitsEndpoint {

    @ReadOperation
    public Map fruits() { ... }

    @WriteOperation
    public void addFruits(@Selector String name, Fruit fruit) { ... }
}

Depois de registrarFruitsEndpoint em nossoApplicationContext,, ele pode ser exposto como um endpoint da web usando nossa tecnologia escolhida. Também podemos expô-lo via JMX, dependendo da nossa configuração.

A conversão de nosso terminal em terminais da Web resultaria em:

  • GET em/application/fruits retornando frutas

  • POST em/applications/fruits/{a-fruit} manipulando aquela fruta que deve ser incluída na carga útil

Existem muito mais possibilidades. Poderíamos recuperar dados mais granulares. Além disso, poderíamos definir implementações específicas por tecnologia subjacente (por exemplo, JMX vs. Rede). Para o propósito do artigo, vamos mantê-lo como uma introdução simples, sem entrar em muitos detalhes.

4.3. Segurança no Atuador

O Spring Boot 1.x Actuator define seu próprio modelo de segurança. Esse modelo de segurança é diferente daquele usado por nosso aplicativo.

Essa foi a raiz de muitos pontos problemáticos quando os usuários estavam tentando refinar a segurança.

No 2.x, a configuração de segurança deve ser configurada usando a mesma configuração que o resto do aplicativo usa.

Por padrão, a maioria dos pontos de extremidade do atuador está desativada. Isso é independente de o Spring Security estar no caminho de classe ou não. Além destatus einfo,, todos os outros terminais precisam ser habilitados pelo usuário.

4.4. Outras Mudanças Importantes

  • A maioria das propriedades de configuração agora estão emmanagement.xxx, por exemplo:management.endpoints.jmx

  • Alguns pontos de extremidade têm um novo formato. e.g.: env, flyway or liquibase

  • Caminhos de terminal predefinidos não são mais configuráveis

5. Experiência de desenvolvimento aprimorada

5.1. Melhor Feedback

O Spring boot introduziudevtools em 1.3.

Ele cuida de suavizar os problemas típicos de desenvolvimento. Por exemplo, armazenamento em cache de tecnologias de exibição. Ele também executa reinicializações automáticas e recarga ao vivo do navegador. Além disso, ele nos permite depurar aplicativos remotamente.

In 2.x when our application gets restarted by devtools a ‘delta' report will be printed out. Este relatório indicará o que mudou e o impacto que isso pode ter em nosso aplicativo.

Digamos que definamos uma fonte de dados JDBC substituindo aquela configurada pelo Spring Boot.

Devtools indicará que o autoconfigurado não foi mais criado. Ele também apontará a causa, uma correspondência adversa em@ConditionalOnMissingBean para o tipojavax.sql.DataSource. Devtools imprimirá este relatório assim que ele reiniciar.

5.2. Breaking Changes

Devido a problemas no JDK 9, o devtools está descartando o suporte à depuração remota por meio de HTTP.

6. Sumário

Neste artigo, abordamos algumas das alterações que o Spring Boot 2 trará.

Discutimos dependências e como o Java 8 se torna a versão mínima suportada.

Em seguida, falamos sobre configuração automática. Nós nos concentramos em segurança, entre outros. Também falamos sobre o atuador e as muitas melhorias que ele recebeu.

Por fim, falamos sobre alguns pequenos ajustes que ocorreram nas ferramentas de desenvolvimento fornecidas.

Related