Categoria: Spring

Spring Framework 5.0.4 Disponível

Novo Spring Framework 5.0.4 está disponível agora. Esta versão de manutenção é a base para o próximo candidato a segunda versão do Spring Boot 2 e inclui 59 reparações e melhorias selecionadas. Para mais informações veja Project Page | GitHub | Issues | Documentation.

“Portanto, agora existem estas três coisas: a fé, a esperança e o amor. Porém a maior delas é o amor.” 1 Coríntios 13:13

Anúncios

Spring Framework 5.0.3 and 4.3.14

Spring Framework 5.0.3 e 4.3.14 estão disponíveis a partir dessa semana, como outro par de lançamentos e refinamento que são recomendados como atualizações imediatas para todos os usuários! Para todas as informações, veja blog oficial.

“É melhor ser pobre e temer a Deus, o SENHOR, do que ser rico e infeliz.” Provérbios 15:16

Não fique amarrado com o Spring

homem-de-negcios-amarrado-na-corda-2431821Eu praticamente faço tudo com Spring Framework. Ele simplesmente é o camisa 10 de todos os meus projetos nesses últimos 10 anos. Mas eu também não nego o benefício de usar um produto Java baseado em especificação. Quando você inicia sua carreira em java, não da muita bola para as especificações, até ter a experiência de migrar, trocar e/ou alterar uma solução e ver as consequências de usar uma especificação. A ficha caiu para mim quando migrei soluções de décadas usando banco de dados relacionais com JDBC e um outro com JPA. Demorei simplesmente algumas fáceis horas enquanto outras produtos de outras plataformas dentro da  mesma empresa, precisaram de 9 meses para fazer o mesmo. Migrei vários provedores de JSF em soluções web alguns bons anos também com muita facilidade e segurança. Tive outros exemplos legais também, que vou deixar para uma próxima.

O Spring é um produto proprietário e sendo assim você inevitavelmente acaba ficando amarrado com ele, sua versão e seus pacotes. Por exemplo: Se você use o modulo de IoC, vai acabar usando o import da anotação org.springframework.stereotype.Component. Quando essa anotação mudar de pacote, for substituída por uma outra ou você migrar de provedor de IoC, já era seu projeto! Quebra tudo e perde portabilidade.

“Seria possível usar o Spring e não ficar amarrado com ele?”

Sim, existem varias formas diferentes de fazer isso. Hoje quero dar 3 dicas que tenho usado nos últimos anos para reduzir a dependência e amarração para o framework Spring.

1. Não use anotações proprietários de IoC

O modulo de IoC do spring funciona perfeitamente com a especificação CDI. Assim, você pode parar de usar anotações proprietárias @Component, @Controler, @Repository, @Service, @Autowire e etc. Ao invés disso, use especificação CDI @Named, @Inject e @Resource. É claro que iremos perder os tratamentos de exceptions automáticas existente nas anotações spring e outros detalhes, mas você acaba retirando dependência desses pacotes de seu projeto. A maioria dos projetos tem tratamento de erros customizados e não dependente desses serviços. Então, analise e veja o que vale mais a pena. Segue abaixo alguns links sobre o assunto:

  1. https://www.mkyong.com/spring3/spring-3-and-jsr-330-inject-and-named-example/
  2. https://mobiarch.wordpress.com/2013/01/11/spring-di-and-cdi-comparative-study/

2. Não use anotações proprietários de escopo web

Quando você integra um JSF com container IoC do spring, é obrigado a usar as anotações de escopo proprietária para declarar ciclo de vida do seus managed beans. Você também não precisa usar elas. Nas ultimas versões do spring saiu um recurso muito bacana chamado de Meta Anotations Support. Resumidamente, é ato de criar suas próprias anotações customizadas reusando e/ou evitando DRY de anotações spring dentro de seus beans. Usando esse recurso, você poderia criar suas próprias anotações de escopo, evitando espalhar repetidamente o import de pacotes proprietários do spring dentro de seus projetos. Segue abaixo um exemplo meu:

sem-titulo

Assim, nos seus managed beans, você evita o import dos org.springframework.context.annotations.Scope, usando então sua própria anotação. Veja um exemplo de managed bean:

sem-titulo2

3. Não use anotações proprietários de transação

Uma das coisas que eu acredito ser mais utilizadas do modulo de transação do spring é a facilidade e a simplicidade da anotação @Transaction do pacote org.springframework.transaction.annotation. Com ela, o spring aplica AOP recursiva em suas transações de modo fácil e rápido. O que você não parou para pensar é que o seu domain model (DDD) acaba importando esse pacote proprietário em um bilhão de classes, ficando totalmente amarrado com o spring no uso desse serviço, furando o conceito mais básico e clássico DDD de um projeto que é a independência de produto, serviço ou framework. Pare de fazer isso! Aplique o mesmo caso do item 2 acima. Crie sua anotação de transação customizada e reuse no seu DDD. Segue um exemplo:

sem-titulo3

Assim, nos seus beans transacionais, você evita o import dos org.springframework.transaction.annotationusando então sua própria anotação. Veja um exemplo:

sem-titulo4

Com essas três dicas simples, você elimina a maioria dos imports proprietários do spring framework para dentro do seu projeto, deixando seu código independente, mais flexível e limpo. Você continua usando o melhor e maior framework java da história, e consegue manter as camadas do seu projeto independente de serviço e detalhes infraestruturais! Até a próxima pessoal 😉

“Para ser sábio, é preciso primeiro temer a Deus, o SENHOR. Os tolos desprezam a sabedoria e não querem aprender.” Provérbios 1:7

Novidades do Spring Framework

Segue abaixo um resumo das novidades do spring framework 5:

JDK 8+ and Java EE 7+ Baseline

  • Entire framework codebase based on Java 8 source code level now.
    • Improved readability through inferred generics, lambdas, etc.
    • Conditional support for Java 8 features now in straight code.
  • Full compatibility with JDK 9 for development and deployment.
    • On classpath as well as module path (with stable automatic module names).
    • Framework build and test suite passes on JDK 9 (runs on JDK 8 by default).
  • Java EE 7 API level required in Spring’s corresponding features now.
    • Servlet 3.1, Bean Validation 1.1, JPA 2.1, JMS 2.0
    • Recent servers: e.g. Tomcat 8.5+, Jetty 9.4+, WildFly 10+
  • Compatibility with Java EE 8 API level at runtime.
    • Servlet 4.0, Bean Validation 2.0, JPA 2.2, JSON Binding API 1.0
    • Tested against Tomcat 9.0, Hibernate Validator 6.0, Apache Johnzon 1.1

Removed Packages, Classes and Methods

  • Package beans.factory.access (BeanFactoryLocator mechanism).
  • Package jdbc.support.nativejdbc (NativeJdbcExtractor mechanism).
  • Package mock.staticmock removed from spring-aspects module.
    • No support for AnnotationDrivenStaticEntityMockingControl anymore.
  • Packages web.view.tiles2 and orm.hibernate3/hibernate4 dropped.
    • Minimum requirement: Tiles 3 and Hibernate 5 now.
  • Dropped support: Portlet, Velocity, JasperReports, XMLBeans, JDO, Guava.
    • Recommendation: Stay on Spring Framework 4.3.x for those if needed.
  • Many deprecated classes and methods removed across the codebase.
    • A few compromises made for commonly used methods in the ecosystem.

General Core Revision

  • JDK 8+ enhancements:
    • Efficient method parameter access based on Java 8 reflection enhancements.
    • Selective declarations of Java 8 default methods in core Spring interfaces.
    • Consistent use of JDK 7 Charset and StandardCharsets enhancements.
  • JDK 9 compatibility:
    • Avoiding JDK APIs which are deprecated in JDK 9 wherever possible.
    • Consistent instantiation via constructors (with revised exception handling).
    • Defensive use of reflection against core JDK classes.
  • Non-null API declaration at the package level:
    • Nullable arguments, fields and return values explicitly annotated with @Nullable.
    • Primarily for use with IntelliJ IDEA and Kotlin, but also Eclipse and FindBugs.
    • Some Spring APIs are not tolerating null values anymore (e.g. in StringUtils).
  • Resource abstraction provides isFile indicator for defensive getFile access.
    • Also features NIO-based readableChannel accessor in the Resource interface.
    • File system access via NIO.2 streams (no FileInput/OutputStream used anymore).
  • Spring Framework 5.0 comes with its own Commons Logging bridge out of the box:
    • spring-jcl instead of standard Commons Logging; still excludable/overridable.
    • Autodetecting Log4j 2.x, SLF4J, JUL (java.util.logging) without any extra bridges.
  • spring-core comes with ASM 6.0 (next to CGLIB 3.2.5 and Objenesis 2.6).

Core Container

  • Support for any @Nullable annotations as indicators for optional injection points.
  • Functional style on GenericApplicationContext/AnnotationConfigApplicationContext
    • Supplier-based bean registration API with bean definition customizer callbacks.
  • Consistent detection of transaction, caching, async annotations on interface methods.
    • In case of CGLIB proxies.
  • XML configuration namespaces streamlined towards unversioned schemas.
    • Always resolved against latest xsd files; no support for deprecated features.
    • Version-specific declarations still supported but validated against latest schema.
  • Support for candidate component index (as alternative to classpath scanning).

Spring Web MVC

  • Full Servlet 3.1 signature support in Spring-provided Filter implementations.
  • Support for Servlet 4.0 PushBuilder argument in Spring MVC controller methods.
  • MaxUploadSizeExceededException for Servlet 3.0 multipart parsing on common servers.
  • Unified support for common media types through MediaTypeFactory delegate.
    • Superseding use of the Java Activation Framework.
  • Data binding with immutable objects (Kotlin / Lombok / @ConstructorProperties)
  • Support for the JSON Binding API (as an alternative to Jackson and GSON).
  • Support for Jackson 2.9.
  • Support for Protobuf 3.
  • Support for Reactor 3.1 Flux and Mono as well as RxJava 1.3 and 2.1 as return values from Spring MVC controller methods targeting use of the new reactive WebClient (see below) or Spring Data Reactive repositories in Spring MVC controllers.
  • New ParsingPathMatcher alternative to AntPathMatcher with more efficient parsing and extended syntax.
  • @ExceptionHandler methods allow RedirectAttributes arguments (and therefore flash attributes).
  • Support for ResponseStatusException as a programmatic alternative to @ResponseStatus.
  • Support script engines that do not implement Invocable via direct rendering of the script provided using ScriptEngine#eval(String, Bindings), and also i18n and nested templates in ScriptTemplateView via the new RenderingContext parameter.
  • Spring’s FreeMarker macros (spring.ftl) use HTML output formatting now (requiring FreeMarker 2.3.24+).

Spring WebFlux

  • New spring-webflux module, an alternative to spring-webmvc built on a reactive foundation — fully asynchronous and non-blocking, intended for use in an event-loop execution model vs traditional large thread pool with thread-per-request execution model.
  • Reactive infrastructure in spring-core such as Encoder and Decoder for encoding and decoding streams of Objects; DataBuffer abstraction, e.g. for using Java ByteBuffer or Netty ByteBufReactiveAdapterRegistry for transparent support of reactive libraries in controller method signatures.
  • Reactive infrastructure in spring-web including HttpMessageReader and HttpMessageWriterthat build on and delegate to Encoder and Decoder; server HttpHandler with adapters to (non-blocking) runtimes such as Servlet 3.1+ containers, Netty, and Undertow; WebFilterWebHandler and other non-blocking contract alternatives to Servlet API equivalents.
  • @Controller style, annotation-based, programming model, similar to Spring MVC, but supported in WebFlux, running on a reactive stack, e.g. capable of supporting reactive types as controller method arguments, never blocking on I/O, respecting backpressure all the way to the HTTP socket, and running on extra, non-Servlet containers such as Netty and Undertow.
  • New functional programming model (“WebFlux.fn”) as an alternative to the @Controller, annotation-based, programming model — minimal and transparent with an endpoint routing API, running on the same reactive stack and WebFlux infrastructure.
  • New WebClient with a functional and reactive API for HTTP calls, comparable to the RestTemplate but through a fluent API and also excelling in non-blocking and streaming scenarios based on WebFlux infrastructure; in 5.0 the AsyncRestTemplate is deprecated in favor of the WebClient.

Kotlin support

  • Null-safe API when using Kotlin 1.1.50+
  • Support for Kotlin immutable classes with optional parameters and default values
  • Functional bean definition Kotlin DSL.
  • Functional routing Kotlin DSL for WebFlux.
  • Leveraging Kotlin reified type parameters to avoid specifying explicitly the Class to use for serialization/deserialization in various APIs like RestTemplate or WebFlux APIs.
  • Kotlin null-safety support for @Autowired/@Inject and @RequestParam/@RequestHeader/etc annotations in order to determine if a parameter/bean is required or not.
  • Kotlin script support in ScriptTemplateView for both Spring MVC and Spring WebFlux.
  • Array-like setters added to ModelModelMap and Environement.
  • Support for Kotlin autowired constructor with optional parameters
  • Kotlin reflection is used to determine interface method parameters

Testing Improvements

  • Complete support for JUnit 5‘s Jupiter programming and extension models in the Spring TestContext Framework.
    • SpringExtension: an implementation of multiple extension APIs from JUnit Jupiter that provides full support for the existing feature set of the Spring TestContext Framework. This support is enabled via @ExtendWith(SpringExtension.class).
    • @SpringJUnitConfig: a composed annotation that combines@ExtendWith(SpringExtension.class) from JUnit Jupiter with @ContextConfigurationfrom the Spring TestContext Framework.
    • @SpringJUnitWebConfig: a composed annotation that combines@ExtendWith(SpringExtension.class) from JUnit Jupiter with @ContextConfiguration and @WebAppConfiguration from the Spring TestContext Framework.
    • @EnabledIf: signals that the annotated test class or test method is enabled if the supplied SpEL expression or property placeholder evaluates to true.
    • @DisabledIf: signals that the annotated test class or test method is disabled if the supplied SpEL expression or property placeholder evaluates to true.
  • Support for parallel test execution in the Spring TestContext Framework.
  • New before and after test execution callbacks in the Spring TestContext Framework with support for TestNG, JUnit 5, and JUnit 4 via the SpringRunner (but not via JUnit 4 rules).
    • New beforeTestExecution() and afterTestExecution() callbacks in theTestExecutionListener API and TestContextManager.
  • MockHttpServletRequest now has getContentAsByteArray() and getContentAsString()methods for accessing the content (i.e., request body).
  • The print() and log() methods in Spring MVC Test now print the request body if the character encoding has been set in the mock request.
  • The redirectedUrl() and forwardedUrl() methods in Spring MVC Test now support URI templates with variable expansion.
  • XMLUnit support upgraded to 2.3.

“Portanto, já que vocês aceitaram Cristo Jesus como Senhor, vivam unidos com ele. Estejam enraizados nele, construam a sua vida sobre ele e se tornem mais fortes na fé, como foi ensinado a vocês. E deem sempre graças a Deus.” Colossenses 2:6-7

Spring Framework Reference Documentation

Falta poucas semanas para o lançamento da versão do spring framework 5, mas já foi liberado o acesso a nova documentação de referencia totalmente refatorado e reorganizada. Ficou fantástico! Vejam  https://docs.spring.io/spring-framework/docs/5.0.0.BUILD-SNAPSHOT/spring-framework-reference/

“O Senhor não demora a fazer o que prometeu, como alguns pensam. Pelo contrário, ele tem paciência com vocês porque não quer que ninguém seja destruído, mas deseja que todos se arrependam dos seus pecados.”2 Pedro 3:9

Poster Spring Framework

A Spring é um dos frameworks mais populares para simplificar o desenvolvimento de soluções Java. Ele ajuda os desenvolvedores a criar aplicativos confiáveis e fáceis de manter, reduzindo significativamente o tempo de mercado para projetos complexos. Seus módulos escondem a complexidade de várias tecnologias enterprise, especificações e produtos proprietários, fornecendo uma interface unificada baseada em modelo. O poster abaixo mostra os principais componentes da estrutura e ilustra visualmente como usá-los com amostras de código e diagramas UML simples.

O poster aborda a estrutura geral da estrutura e os módulos amplamente utilizados. Baixe, imprima 24 x 36 e coloca ai na sua parede! Bom final de semana a todos!

“O ladrão só vem para roubar, matar e destruir; mas eu vim para que as ovelhas tenham vida, a vida completa.” João 10:10