Spring Boot, Spring Security e Spring Batch — conceitos essenciais explicados a fundo.
Empacotando uma aplicação Spring Boot como imagem OCI: o Dockerfile escrito à mão do livro, os JARs em camadas que fazem o cache de build do Docker funcionar de verdade, e o spring-boot:build-image como alternativa sem Dockerfile baseada em Cloud Native Buildpacks.
Estenda o Actuator além dos endpoints nativos: contribua dados da aplicação para /info com InfoContributor, escreva um HealthIndicator que reflita uma dependência real, publique métricas de negócio pelo MeterRegistry do Micrometer, crie endpoints customizados com @Endpoint e proteja toda essa superfície com Spring Security e EndpointRequest.
O Actuator adiciona endpoints de prontidão para produção a uma aplicação Spring Boot (/health, /info, /metrics, /env, /beans, /mappings e outros) via HTTP e JMX, além de como expô-los e consumi-los com segurança.
Como a injeção de dependência gerenciada por container evoluiu dos deployment descriptors XML do EJB para a especificação formal Jakarta CDI, e por que @Autowired/@Component e @Inject/@Named são dois dialetos do mesmo modelo subjacente no Spring e no Quarkus.
Como os profiles do Spring permitem que propriedades e beans diferentes se apliquem conforme o profile ativo, por que definir spring.profiles.active fora do application.yml mantém a configuração de cada ambiente bem separada, e como a sintaxe YAML multidocumento spring.profiles: prod do livro foi substituída por spring.config.activate.on-profile.
Como @ConfigurationProperties transforma os setters de qualquer bean em valores vindos da configuração, por que extraí-los para um bean holder dedicado mantém controllers e services limpos, e como gerar metadados de IDE para propriedades customizadas, além de por que records com constructor binding são agora a alternativa preferida a uma classe holder mutável baseada em Lombok.
Como a abstração de environment do Spring reúne propriedades de system properties da JVM, variáveis de ambiente do SO, argumentos de linha de comando e application.yml/properties em uma única fonte, e como algumas centenas de configuration properties nativas (server.port, spring.datasource.*, logging.level.*) permitem ajustar os beans autoconfigurados do Spring Boot sem escrever um único método @Bean.
Como o Spring Framework core, Spring Boot, Spring Data, Spring Security, Spring Batch/Integration e Spring Cloud se encaixam como um único ecossistema, e como esse panorama mudou desde 2019 (namespace Jakarta EE, imagens nativas com GraalVM, os subprojetos atuais do Spring Cloud).
Como @SpringBootApplication, as dependências starter e os beans condicionais permitem que o Spring Boot monte uma aplicação quase sem configuração explícita.
Como o openapi-generator-maven-plugin transforma uma spec OpenAPI em interfaces de controller Spring e DTOs durante o build, usando generatorName=spring, a escolha de library e interfaceOnly mais o delegate pattern para manter a lógica escrita à mão fora do código gerado.
Chamando APIs REST a partir de uma aplicação Spring: as operações do RestTemplate por verbo para GET/PUT/DELETE/POST e a navegação do Traverson por nome de relação em uma API hipermídia, além de onde o RestClient entra hoje.
O pipeline concreto por trás de uma chamada a um controller REST: o RequestMappingHandlerMapping encontrando a rota via PathPattern, o HandlerAdapter resolvendo argumentos e invocando o método por reflection, e o HttpMessageConverter cuidando da (de)serialização JSON nos dois sentidos.
Como adicionar o spring-boot-starter-data-rest expõe todo repositório Spring Data como uma API REST de hipermídia sem nenhum código de controller, como @RepositoryRestResource e @RestResource ajustam paths e exposição, e como o ResourceProcessor do livro virou o RepresentationModelProcessor de hoje para adicionar links customizados.
Como o Spring HATEOAS anexa hiperlinks autodescritivos às respostas REST para que os clientes naveguem pela API por nome de relação em vez de URLs fixas, usando RepresentationModel/EntityModel/CollectionModel, os builders de link linkTo(methodOn(...)) e classes RepresentationModelAssembler que produzem o formato JSON HAL com _links/_embedded.
Como @RestController e as anotações de mapeamento por método HTTP (@GetMapping/@PostMapping/@PutMapping/@PatchMapping/@DeleteMapping) mapeiam operações CRUD em endpoints REST, por que PUT e PATCH têm semânticas realmente diferentes (substituir vs. mesclar) que as anotações sozinhas não garantem, e como o ProblemDetail do Spring Framework 6 (RFC 7807) agora dá a 404s e outras respostas de erro um corpo estruturado em vez de vazio.
Como declarar regras de validação com anotações da Bean Validation em uma classe de domínio e aplicá-las no binding do formulário com @Valid e Errors/BindingResult, e por que o spring-boot-starter-validation agora é uma dependência separada e explícita em vez de transitiva.
Como um controller Spring MVC combina handlers @GetMapping/@PostMapping com um Model para renderizar views e com o binding implícito de command objects para processar envios de formulário, e como os records do Java agora oferecem uma alternativa sem dependências ao Lombok para tipos de domínio imutáveis.
Por que bancos como o Oracle rejeitam uma cláusula IN em JPQL ou SQL com mais de 1000 elementos, e as três formas de contornar isso: dividir os valores em lotes você mesmo, reescrever o filtro como sub-select ou, quando o filtro é pela chave primária, usar o MultiIdentifierLoadAccess do Hibernate (byMultipleIds) para buscar muitas entidades por id em uma chamada sem implementar o loteamento na mão.
Como hibernate.order_inserts e hibernate.order_updates fazem o Hibernate agrupar e reordenar os INSERT/UPDATE pendentes no flush, para que operações na mesma tabela aconteçam em uma ordem consistente entre transações, reduzindo (sem eliminar) deadlocks em clusters multinó como o Galera, e por que evitar locks explícitos continua sendo a primeira recomendação antes de recorrer a essas configurações.
Por que em.find() e a navegação por uma associação to-one podem ser atendidos inteiramente pelo cache de primeiro nível (e de segundo nível), enquanto uma consulta JPQL, Criteria ou nativa sempre vai ao banco, com o Hibernate descartando uma linha do resultado e usando a instância já gerenciada sempre que o cache de primeiro nível já tem aquela entidade; cachear o resultado de uma consulta exige o Query Cache separado, e não os caches de entidade.
Como @NamedStoredProcedureQuery mapeia uma stored procedure do banco no JPA usando entradas @StoredProcedureParameter para parâmetros IN, OUT, INOUT e REF_CURSOR, por que uma consulta de stored procedure precisa ser executada com execute() em vez de getResultList()/getSingleResult(), e como getOutputParameterValue() recupera cada parâmetro de saída depois.
Por que o JPA oferece três APIs de consulta distintas em vez de uma: JPQL é uma linguagem de consulta baseada em strings sobre o seu modelo de entidades (independente do banco, mas limitada ao que o Hibernate consegue traduzir para SQL), a Criteria API expõe esse mesmo conjunto de recursos como uma API Java type-safe que compensa a verbosidade principalmente quando a consulta precisa ser montada dinamicamente a partir da entrada do usuário, e consultas SQL nativas ignoram a abstração por completo para dar acesso total a recursos específicos do banco ao custo da portabilidade. As três protegem igualmente contra SQL injection, mas só se você usar bind parameters em vez de concatenar strings.
Como anotar classes de domínio como entidades JPA e estender CrudRepository entrega uma camada de persistência funcionando sem nenhum código de implementação, e como o Spring Data interpreta nomes de métodos derivados (findByDeliveryZip, readOrdersByDeliveryZipAndPlacedAtBetween) como consultas reais, com @Query como válvula de escape.
Como o JdbcTemplate elimina o boilerplate de conexão/statement/result set do JDBC com query()/queryForObject() e um RowMapper, como o SimpleJdbcInsert simplifica inserts que precisam de uma chave gerada, e como schema.sql/data.sql inicializam o banco automaticamente na subida, além de por que o JdbcClient do Spring Framework 6.1 é agora a fachada fluente recomendada para o mesmo trabalho.
O cliente HTTP não bloqueante do Spring: retrieve()/bodyToMono/bodyToFlux, corpos de requisição reativos, tratamento de erros com onStatus, o exchangeToMono que substitui o exchange() propenso a vazamentos, e o Spring Security reativo com SecurityWebFilterChain.
Construa uma camada web não bloqueante com Spring WebFlux: as mesmas anotações @RestController do Spring MVC, mas retornando Mono e Flux, a alternativa sem anotações com RouterFunction/HandlerFunction, e o WebTestClient para testar os dois contra mocks ou um servidor Netty real.
O vocabulário de operadores de Flux e Mono: criar streams a partir de dados, combinar dois com zip ou mergeWith, transformar com map ou flatMap, filtrar e reduzir um stream a um único resultado lógico.
Por que a programação reativa existe (o problema da thread bloqueada criado por código de I/O imperativo), o contrato de quatro interfaces do Reactive Streams que faz o backpressure funcionar, e os dois tipos centrais de publisher do Reactor: Mono para 0 ou 1 resultado e Flux para sequências de 0 a N.
Como o Spring for Apache Kafka envolve o cliente Kafka puro em um KafkaTemplate autoconfigurado e em @KafkaListener, e por que o modelo do Kafka, baseado em log, reprocessável e ordenado por partição, se comporta de forma diferente do consumo de filas JMS e AMQP.
Como o modelo de exchange, routing key e binding do AMQP desacopla produtores das filas, e como RabbitTemplate e @RabbitListener enviam e recebem mensagens no Spring.
Desacoplando um produtor de um consumidor por meio de um broker JMS: send/convertAndSend do JmsTemplate, message converters e post-processors, e os modelos pull (receive) e push (@JmsListener) de consumo.
Como o @ApplicationModuleTest sobe um módulo por vez, como Scenario e AssertablePublishedEvents testam a colaboração entre módulos por eventos, e como o Documenter gera diagramas C4 e module canvases a partir do mesmo modelo.
Como o @ApplicationModuleListener (assíncrono, depois do commit, em transação própria) e o Event Publication Registry tornam duráveis os eventos entre módulos: as publicações são gravadas na transação de negócio, acompanhadas pelos estados PUBLISHED, COMPLETED e FAILED, reenviadas, e opcionalmente externalizadas para um broker.
Como o Spring Modulith transforma um monolito Spring Boot em um monolito modular: cada subpacote direto é um módulo de aplicação, subpacotes são internos, e ApplicationModules.verify() quebra o build em ciclos, acesso a tipos internos e dependências não declaradas.
Como o ApplicationEventPublisher desacopla quem publica de quem escuta, e por que a escolha entre @EventListener e @TransactionalEventListener (e sua fase) decide se um listener pode vetar a operação, se enxerga trabalho que sofreu rollback, ou se é ignorado em silêncio quando não há transação.
Como verificar a configuração do Spring Security em testes. Method security (@PreAuthorize/@PostAuthorize/@PreFilter/@PostFilter) é testada sem MockMvc, injetando o bean protegido, chamando-o sob @WithMockUser e esperando AuthenticationException sem principal e AccessDeniedException com a authority errada. CSRF é testado com SecurityMockMvcRequestPostProcessors.csrf() e suas variantes asHeader() e useInvalidToken(), sendo o teste mais valioso o POST sem token esperando 403. CORS é testado montando à mão o preflight do navegador como uma requisição OPTIONS com Origin e Access-Control-Request-Method e verificando os headers Access-Control-Allow-Origin/Allow-Methods da resposta, tudo dependendo de a security filter chain estar de fato ligada ao MockMvc via @AutoConfigureMockMvc ou SecurityMockMvcConfigurers.springSecurity(). Do livro para hoje, o código de teste mudou pouco: @EnableGlobalMethodSecurity virou @EnableMethodSecurity, os interceptors agora lançam AuthorizationDeniedException (que estende AccessDeniedException desde a 6.3, então as asserções existentes continuam passando), csrf() não mudou apesar do mascaramento XOR/BREACH padrão da 6.0, o preflight feito à mão continua sendo a única abordagem para CORS, e a origem coringa esperada pelo livro não vale mais com allowedOriginPatterns, que ecoa a origem que casou.
Como o spring-security-test estabelece um principal para o teste: @WithMockUser fabrica um UserDetails sem busca nenhuma (roles ganham o prefixo ROLE_ automaticamente, authorities não; vale no nível da classe e pode ser sobrescrito por método com @WithAnonymousUser), @WithUserDetails carrega um usuário real por um bean UserDetailsService para que o principal seja a sua própria implementação, e uma anotação customizada ligada a uma WithSecurityContextFactory via @WithSecurityContext serve quando o tipo concreto de Authentication importa. As três pulam a autenticação por completo, e por isso o caminho AuthenticationProvider/PasswordEncoder/handlers de sucesso e falha precisa ser exercitado à parte pelo MockMvc com httpBasic() ou o request builder formLogin() mais os matchers authenticated()/unauthenticated(). O idioma JUnit 4 do livro agora é @ExtendWith(SpringExtension.class)/@SpringJUnitConfig (implícito no @SpringBootTest), e springSecurity() é aplicado automaticamente no Spring Boot, mas continua explícito com .apply(springSecurity()) fora dele.
Como um resource server Spring Boot se conecta ao Keycloak como um authorization server real e pronto para uso: configurar realm, client, client scope, usuários e roles no console de administração, obter um JWT no token endpoint, usar protocol mappers para adicionar claims de roles, username e audience, e validar esse JWT offline contra o endpoint JWKS do realm (seleção de chave por kid, então a rotação de chaves funciona), aplicando regras em três camadas (hasAuthority no endpoint, @PreAuthorize no service e um @Query filtrado por SpEL no repositório). O Keycloak segue muito vivo, mas todos os mecanismos do livro mudaram: o runtime WildFly foi trocado por Quarkus no Keycloak 17 (bin/kc.sh em vez de standalone.sh, e /auth saiu de todas as URLs, então o issuer agora é /realms/{realm}), o realm master é só para administração, o password grant vem desligado por padrão em clients novos desde a 26.2, o adapter keycloak-spring-boot-starter do próprio Keycloak foi depreciado e removido, e as classes do Spring Security OAuth que ele usava (@EnableResourceServer, JwkTokenStore) estão em fim de vida. Hoje toda a configuração se resume a spring-boot-starter-oauth2-resource-server mais issuer-uri/audiences, com um JwtAuthenticationConverter mapeando as claims nativas realm_access.roles e preferred_username do Keycloak em vez de remodelar o realm para caber em uma biblioteca morta.
@PreFilter e @PostFilter aplicam uma regra SpEL por elemento (filterObject vs. authentication) para enxugar no lugar uma coleção de argumento ou de retorno, em vez de permitir ou negar a chamada inteira como @PreAuthorize/@PostAuthorize fazem. Isso exige uma coleção mutável, já que o aspecto altera a instância de quem chamou e um List.of() imutável lança UnsupportedOperationException. As duas anotações seguem iguais hoje, exceto pela troca do depreciado @EnableGlobalMethodSecurity(prePostEnabled = true) por @EnableMethodSecurity, e a técnica do capítulo 17.3 do livro (substituir o @PostFilter no repositório por um bean SecurityEvaluationContextExtension mais um predicado ?#{authentication.name} dentro do @Query) continua sendo a recomendação oficial, já que filtrar em memória desperdiça heap e quebra a paginação.
A method security move a autorização da filter chain para a própria chamada de método via um interceptor do Spring AOP: @PreAuthorize avalia uma regra SpEL antes da invocação (usando hasAuthority/hasRole mais argumentos do método via #paramName e a authentication atual) e @PostAuthorize a avalia depois, contra o returnObject especial, com hasPermission() delegando a lógica por objeto a um bean PermissionEvaluator. Hoje o @EnableGlobalMethodSecurity(prePostEnabled = true) do livro está depreciado em favor do @EnableMethodSecurity (desde a 5.6), que liga as anotações pre/post por padrão, troca a pilha de voters por interceptors baseados em AuthorizationManager e um Supplier<Authentication> adiado, e, o mais importante, não detecta mais automaticamente um PermissionEvaluator customizado: ele precisa ser ligado por um bean estático MethodSecurityExpressionHandler, senão todo hasPermission() nega silenciosamente.
Como um resource server valida um JWT localmente checando sua assinatura: HMAC simétrico (HS256), em que um único segredo compartilhado assina e verifica (então todo resource server que o tem também pode emitir tokens), contra um par de chaves RSA assimétrico (RS256), em que o authorization server assina com a chave privada e qualquer número de resource servers verifica com uma chave pública que pode ser publicada livremente, além de como adicionar e ler claims customizadas. A pilha JwtTokenStore/JwtAccessTokenConverter/TokenEnhancer do Spring Security OAuth usada no livro está em fim de vida e corresponde hoje a JwtEncoder/JwtDecoder baseados em Nimbus, OAuth2TokenCustomizer e Jwt.getClaim(), enquanto o endpoint improvisado /oauth/token_key do livro é exatamente o que o endpoint padrão JWK Set (RFC 7517, descoberto pelo jwks_uri da RFC 8414; /oauth2/jwks no Spring Authorization Server) formaliza, acrescentando a rotação de chaves por kid que a configuração PEM estática do livro não permite.
O resource server precisa validar um bearer token que não emitiu e que (com tokens UUID opacos) não consegue ler, o que leva a exatamente três estratégias: chamar o endpoint check_token do authorization server a cada requisição, fazer blackboarding com um banco compartilhado via JdbcTokenStore, ou verificar uma assinatura localmente, com trade-offs de latência por requisição, acoplamento de disponibilidade e atraso de revogação. Hoje a API do livro (@EnableResourceServer, ResourceServerConfigurerAdapter, TokenStore) está em fim de vida: a checagem remota virou introspecção RFC 7662 configurada com oauth2ResourceServer(...).opaqueToken() (ou três propriedades spring.security.oauth2.resourceserver.opaquetoken.*), a validação local é .jwt() com um NimbusJwtDecoder que busca o JWK set de forma preguiçosa para não acoplar a inicialização ao IdP, e o blackboarding não tem sucessor oficial: o JdbcTokenStore nunca foi portado (issue #9381 fechada como duplicada) e sobrevive só como um OpaqueTokenIntrospector customizado, mais útil para cachear respostas de introspecção do que para compartilhar um schema entre os dois servidores.
Construindo o componente que emite access tokens. O livro faz isso com o @EnableAuthorizationServer e o ClientDetailsService do projeto Spring Security OAuth, hoje arquivado, que chegou ao fim da vida em 2022 e foi substituído pelo Spring Authorization Server independente (beans RegisteredClient/RegisteredClientRepository/AuthorizationServerSettings), que por sua vez foi reincorporado ao Spring Security a partir do Spring Security 7.0. Dos quatro grant types do livro, só authorization code e client credentials sobrevivem diretamente no projeto moderno: password não é suportado de forma alguma (nunca foi implementado e está depreciado no OAuth 2.1) e o suporte a refresh token é automático em vez de configurado à parte.
Construindo o menor ator do OAuth2: uma aplicação client que redireciona para o authorization server de outra pessoa, troca o code recebido por um token e lê os dados do usuário, sem usuários, tokens ou recursos protegidos próprios. O Spring Security modela isso com ClientRegistration (o registro de um client em um provider), ClientRegistrationRepository e o método oauth2Login() do HttpSecurity, que autoconfigura quase tudo a partir de algumas propriedades spring.security.oauth2.client.registration.*. A API (ClientRegistration, OAuth2AuthenticationToken, OidcUser) mudou pouco desde 2020; as principais mudanças são o SecurityFilterChain com DSL de lambdas no lugar do WebSecurityConfigurerAdapter e authorizeHttpRequests() no lugar de authorizeRequests().
O modelo mental do OAuth 2 (resource owner, client com seu próprio client_id/client_secret, authorization server e resource server trocando access tokens limitados por escopo), quando escolher cada grant type (os dois round trips do authorization code e o porquê, password, client credentials, refresh token) e os "pecados do OAuth 2" apontados pelo próprio livro. Desde 2020 o password grant passou de desencorajado a proibido (a RFC 9700/BCP 240 diz MUST NOT, o OAuth 2.1 o omite, AuthorizationGrantType.PASSWORD está depreciado no Spring Security 6.x e sumiu na 7.0, e o Spring Authorization Server nunca o suportou), enquanto o PKCE passou de reforço opcional a obrigatório para todo client de authorization code, junto com a comparação exata de redirect URI e a proibição de bearer tokens em query strings.
Uma montagem prática com dois servidores (um servidor de autenticação que guarda as credenciais e emite tokens de uso único, e um servidor de lógica de negócio que confia em um bearer token a cada requisição, sem sessão no servidor) expressa inteiramente nos contratos do próprio Spring Security (Authentication, AuthenticationProvider, OncePerRequestFilter, SecurityContextHolder). É uma pedagogia propositalmente anterior ao OAuth2, que mostra o que um fluxo de bearer token precisa fazer antes de o framework entregar OAuth2/OIDC para fazer isso de forma padronizada. O filtro da era javax e a configuração com WebSecurityConfigurerAdapter do livro correspondem hoje a jakarta.servlet mais um bean SecurityFilterChain, e sistemas em produção usam o Spring Authorization Server (RegisteredClient/JWT) em vez de implementar esse mecanismo à mão, embora os contratos que este conceito ensina não tenham mudado.
CORS é um mecanismo do navegador que relaxa a same-origin policy, e não uma restrição do servidor: uma chamada cross-origin sem configuração ainda executa no servidor, só a resposta é escondida do JavaScript. Ele é configurado por endpoint com o @CrossOrigin do Spring MVC ou de forma central com http.cors() mais um CorsConfigurationSource, cujo CorsFilter precisa rodar antes da autenticação e da autorização do Spring Security para que preflights OPTIONS sem credenciais não sejam rejeitados com 401. O WebSecurityConfigurerAdapter.configure(HttpSecurity) do livro agora é um bean SecurityFilterChain e a lambda crua virou um bean UrlBasedCorsConfigurationSource, enquanto CorsConfiguration, @CrossOrigin e http.cors() continuam iguais; as novidades são originPatterns (obrigatório no lugar do coringa quando allowCredentials é true), preFlightRequestHandler e o WHATWG Fetch Standard substituindo a especificação CORS do W3C citada pelo livro para as regras de simple request.
O CsrfFilter fica na filter chain, deixa GET/HEAD/TRACE/OPTIONS passarem sem mexer e exige um token (entregue antes ao cliente por um CsrfTokenRepository) para qualquer outro método. Por isso um projeto Spring Security novo rejeitando com 403 um POST autenticado é a proteção CSRF funcionando como projetada, não um bug: a correção é devolver o token (campo oculto de formulário em apps renderizadas no servidor, um cookie via CookieCsrfTokenRepository em SPAs) ou, quando fizer sentido de verdade, excluir request matchers específicos ou desligar a proteção em APIs só com bearer token. Desde o Spring Security 6.1 o handler padrão para ler o token passou a ser o XorCsrfTokenRequestAttributeHandler (resistente a BREACH, com carregamento adiado do token) no lugar do padrão mais simples do livro.
O HttpSecurity do Spring Security expõe exatamente três posições para um Filter customizado em relação a um filtro nativo conhecido: addFilterBefore() para rejeitar requisições ruins antes que a autenticação cara rode, addFilterAfter() para observar o que já passou, e addFilterAt() para colocar a sua implementação de uma responsabilidade que normalmente é de um filtro nativo (atenção: addFilterAt NÃO remove o filtro ao lado, os dois continuam rodando), além do catálogo de filtros que o Spring Security traz. O javax.servlet.Filter e o override de WebSecurityConfigurerAdapter.configure(HttpSecurity) do livro agora são jakarta.servlet.Filter (namespace Jakarta EE do Spring Boot 3.0+) e um bean SecurityFilterChain usando os mesmos três métodos de builder.
Como regexMatchers() casa o path completo de uma requisição contra uma expressão regular quando os matchers MVC e Ant não conseguem expressar a regra — como uma condição que abrange duas variáveis de path ao mesmo tempo — e por que o conselho do próprio livro de preferir matchers legíveis ainda vale hoje, via o RegexRequestMatcher, explícito e ainda atual.
Como antMatchers() compartilha sua sintaxe de wildcard com mvcMatchers() mas casa apenas com a expressão de caminho literal, por que isso deixa um caminho como /hello/ desprotegido quando uma regra é escrita para /hello, e por que requestMatchers() e o próprio default de correspondência de barra final do Spring mudaram desde a recomendação do livro de preferir matchers MVC.
Como os matcher methods do Spring Security (anyRequest(), mvcMatchers()/requestMatchers()) selecionam a quais requests uma regra de autorização se aplica, por que a ordem das regras precisa ir do específico para o geral, como combinar um caminho com um método HTTP, e por que o próprio argumento de segurança do livro para preferir matchers MVC a matchers Ant agora está embutido por padrão em requestMatchers().
Como o Spring Security decide, depois que a autenticação dá certo, se uma requisição é de fato permitida: pelo contrato GrantedAuthority, pelos métodos hasAuthority()/hasAnyAuthority() para authorities de granularidade fina, por hasRole()/hasAnyRole() e a convenção do prefixo ROLE_ para roles mais amplas, e por denyAll() para restrições gerais, além da válvula de escape do método access() para SpEL puro em tudo que os métodos nomeados não conseguem expressar.
Como httpBasic() e formLogin() configuram os dois métodos de autenticação nativos do Spring Security, como AuthenticationEntryPoint/AuthenticationSuccessHandler/AuthenticationFailureHandler customizam o comportamento de falha e de sucesso, e como os dois métodos podem conviver na mesma aplicação.
Como o SecurityContextHolder guarda o Authentication após o login por meio de três estratégias (MODE_THREADLOCAL, MODE_INHERITABLETHREADLOCAL, MODE_GLOBAL), e como DelegatingSecurityContextCallable/ExecutorService propagam o contexto de segurança para threads gerenciadas por você que o framework não conhece.
Como o Spring Security representa uma requisição de autenticação em andamento ou concluída pela interface Authentication, e como o par authenticate()/supports() do AuthenticationProvider permite que vários esquemas de autenticação convivam atrás de um único AuthenticationManager.
Como os KeyGenerators produzem valores de salt e chave (StringKeyGenerator, BytesKeyGenerator) e como os Encryptors criam objetos de criptografia e descriptografia (AES/CBC padrão, AES/GCM mais forte, queryableText para texto cifrado pesquisável) sem trazer uma biblioteca de criptografia separada.
Como o contrato encode()/matches() do PasswordEncoder valida senhas sem nunca reverter um hash, como o DelegatingPasswordEncoder permite que uma aplicação suporte vários algoritmos ao mesmo tempo via um esquema de prefixo, e por que o Argon2 é hoje uma recomendação mais forte do que o trio bcrypt/scrypt/PBKDF2 do livro.
Como o JdbcUserDetailsManager gerencia usuários em um banco relacional via JDBC puro (schema padrão, consultas que podem ser sobrescritas) e como o LdapUserDetailsManager autentica contra um diretório LDAP, ambos implementando o contrato UserDetailsManager.
Como UserDetails, GrantedAuthority, UserDetailsService e UserDetailsManager descrevem e gerenciam usuários no Spring Security, e por que envolver uma entidade JPA em um wrapper UserDetails separado mantém as preocupações de persistência e de segurança apartadas.
Como o filtro de autenticação, o AuthenticationManager, o AuthenticationProvider, o UserDetailsService e o SecurityContextHolder se encaixam, e como configurá-los hoje com SecurityFilterChain em vez do depreciado WebSecurityConfigurerAdapter.
Como funcionam as camadas de teste com contexto Spring: o Spring TestContext Framework (@SpringJUnitConfig, cache de contexto, @DirtiesContext) mais um datasource H2 embarcado para testes de integração que pegam erros de configuração que testes unitários não pegam; o StepScopeTestExecutionListener e seu método de fábrica getStepExecution (ou StepScopeTestUtils.doInStepScope) para exercitar beans @StepScope e SpEL com late binding fora de um step em execução, usando objetos de domínio criados com MetaDataInstanceFactory; e testes funcionais que lançam um step real ou um job inteiro e verificam JobExecution, BatchStatus, contagens de StepExecution e linhas de tabela. Inclui a migração do @RunWith(SpringJUnit4ClassRunner.class) do livro para o @SpringBatchTest, do agora depreciado JobLauncherTestUtils.launchJob/launchStep para JobOperatorTestUtils.startJob/startStep, e o abandono do helper AssertFile, que foi removido.
Jobs de batch rodam sem interface para revelar uma falha silenciosa, então testar importa mais do que o normal. Este conceito cobre a camada de teste unitário caixa-branca sem nenhum contexto Spring: fixtures JUnit simples para um Validator ou ItemProcessor POJO; mock/when/thenReturn/verify/times/never/verifyNoMoreInteractions do Mockito para substituir um FieldSet, um JdbcTemplate ou um writer de arquivo de rejeitados e exercitar ramos sem banco nem sistema de arquivos; spies mais RETURNS_DEEP_STUBS para um JobParametersValidator; e o MetaDataInstanceFactory do spring-batch-test para montar fixtures de StepExecution/JobExecution/ExecutionContext (mais um StepContribution e um ChunkContext feitos à mão), de modo que um JobExecutionDecider, StepExecutionListener ou Tasklet possa ser testado sem lançar um job. O estilo JUnit 4 do livro de 2012 (@RunWith(MockitoJUnitRunner), @Before/@After, @Test(expected=...)) corresponde ao Jupiter (@ExtendWith(MockitoExtension.class), @BeforeEach/@AfterEach, assertThrows), já que o Spring Batch 6.0 abandonou o JUnit 4 por completo; a API central do Mockito não mudou na 5.x além de exigir Java 11+, do inline mock maker, da remoção de verifyZeroInteractions e dos strict stubs; e a reorganização da 6.0 moveu os objetos de domínio (core.job, core.step, core.job.parameters, infrastructure.item), enquanto ItemWriter.write agora recebe Chunk em vez de List e JobParametersInvalidException virou InvalidJobParametersException.
Como um step manager divide os dados de entrada em partições que rodam, cada uma, como sua própria StepExecution de um step worker intocado; a SPI de particionamento (um Partitioner que devolve um Map de ExecutionContexts nomeados, o StepExecutionSplitter e um PartitionHandler que decide entre threads locais via TaskExecutorPartitionHandler ou workers remotos via MessageChannelPartitionHandler); como o gridSize e o late binding #{stepExecutionContext[...]} alimentam parâmetros por partição; por que o reinício funciona sem mensageria durável; e como o particionamento se compara a steps multithreaded, steps paralelos e remote chunking. Inclui as mudanças do Spring Batch 6.0: vocabulário manager/worker, classes de partição realocadas para org.springframework.batch.core.partition, o JobExplorer incorporado ao JobRepository, o XML substituído pelo PartitionStepBuilder e duas novas estratégias (chunking local e remote step).
O remote chunking distribui um step orientado a chunks entre JVMs: um master mantém o ItemReader, o JobRepository e o step, e despacha ChunkRequests por um middleware durável com entrega garantida (JMS/AMQP) para slaves que processam, escrevem e devolvem só um resumo StepContribution. Por isso ele só compensa quando a leitura não é o gargalo, e, ao contrário do particionamento, depende da reentrega transacional e não de metadados de batch por chunk para ser correto. Os canais Spring Integration montados à mão, o gateway MessagingTemplate, o RemoteChunkHandlerFactoryBean e o ChunkProcessorChunkHandler do livro (distribuídos à parte com o Spring Batch Admin) viraram hoje o @EnableBatchIntegration do módulo spring-batch-integration mais RemoteChunkingManagerStepBuilder/RemoteChunkingWorkerBuilder, com a terminologia manager/worker, o ChunkHandler renomeado para ChunkRequestHandler, o ChunkProvider depreciado na 6.0 sem substituto, os argumentos do ChunkProcessor reordenados e duas novidades irmãs na 6.0: chunking local via ChunkTaskExecutorItemWriter e execução remota de step via RemoteStep.
Como escalar um step do Spring Batch em uma única máquina com um step multithreaded apoiado em TaskExecutor ou com flows paralelos independentes unidos por um split, a tensão entre thread safety e capacidade de reinício que isso cria para readers com estado (saveState=false, um reader sincronizado ou o process-indicator pattern), e o redesenho do Spring Batch 6.0, em que só o ItemProcessor roda em várias threads, além de executors com virtual threads para trabalho limitado por I/O.
Como detectar falhas de jobs e agir sobre elas lendo o histórico de execução do job repository: o JobExplorer somente leitura com objetos de domínio ricos, o JobOperator tipado com String/Long pensado para JMX, consultas diretas às tabelas de metadados BATCH_* e alertas disparados de um JobExecutionListener, além da mudança do JMX feito à mão e do descontinuado Spring Batch Admin para as métricas nativas do Micrometer e o Spring Cloud Data Flow.
Como passar um valor de um step para outro posterior de forma segura para reinício via o ExecutionContext persistido do job e o ExecutionContextPromotionListener, em comparação com um bean holder mais simples porém inseguro em reinícios, como externalizar uma sequência reutilizável de steps como Flow/FlowStep/JobStep, e como terminar, falhar ou parar para reinício (end/fail/stopAndRestart) um job de forma declarativa a partir do exit status de um step.
Como o Spring Batch ramifica o fluxo de um job pelo ExitStatus (uma String) de um step, e não pelo enum BatchStatus persistido, usando on() com os coringas * e ?, como criar um exit status customizado a partir de StepExecutionListener.afterStep() ou de um JobExecutionDecider, e os terminadores de fluxo end/fail/stopAndRestart, além da migração do depreciado namespace XML de batch para a DSL Java FlowBuilder.
Como o Spring Batch mantém um step atômico entre dois recursos transacionais, como uma fila JMS e um banco de dados, usando transações globais XA/JTA, o shared-resource pattern, o best-effort 1PC e o tratamento de duplicados por deduplicação ou idempotência.
Como o Spring Batch conduz transações no nível do step (uma transação por chunk, conforme o commit-interval, ou por Tasklet.execute()), como sobrescrever isolation, propagation e timeout com atributos de transação, as armadilhas de transações declarativas e de readers transacionais (JMS), e como o modelo PlatformTransactionManager, que não mudou, corresponde aos métodos de builder .transactionManager()/.transactionAttribute() de hoje, ao jakarta.transaction e ao ResourcelessTransactionManager realocado.
Como o Spring Batch reinicia um job FAILED ou STOPPED lançando uma nova JobExecution da mesma JobInstance, que retoma a partir do estado persistido no ExecutionContext: habilitar ou proibir o reinício com preventRestart, reexecutar steps concluídos com allowStartIfComplete, limitar tentativas com startLimit e retomar no meio de um chunk com um reader ItemStream, tudo exigindo um JobRepository JDBC persistente, além da mudança no Spring Batch 6.0 para JobOperator.restart(JobExecution) e a nova operação recover().
Como o Spring Batch tenta de novo falhas transitórias em vez de pulá-las ou falhar: objetos RetryPolicy com back-off, ganchos RetryListener, o RetryTemplate avulso para código arbitrário e o retry transparente via AOP, além da trajetória da API de retry do pacote próprio do Spring Batch para a biblioteca Spring Retry e, no Spring Batch 6.0, para o retry nativo do core do Spring Framework 7.
Como o Spring Batch pula itens com defeito em vez de falhar o step: a semântica de skip em leitura, processamento e escrita, implementações customizadas de SkipPolicy e callbacks de SkipListener para registrar ou mandar para uma dead letter os registros pulados.
Como um ItemProcessor do Spring Batch filtra itens retornando null (um filtro, não um skip), os valida com ValidatingItemProcessor e o BeanValidatingItemProcessor nativo, e encadeia regras com CompositeItemProcessor.
Como um ItemProcessor fica entre o reader e o writer em um step orientado a chunks para transformar itens no lugar, converter o tipo lido em um tipo de escrita diferente ou completar os dados de uma consulta principal, além do PassThroughItemProcessor e do ItemProcessorAdapter.
Como o Spring Batch reaproveita um serviço existente como writer com ItemWriterAdapter, implementa um ItemWriter customizado através do contrato write(Chunk), e distribui ou roteia um chunk com CompositeItemWriter versus ClassifierCompositeItemWriter — além dos writers de nicho JMS e email — e como essas classes se mudaram para os pacotes org.springframework.batch.infrastructure.item.* no Spring Batch 6.0.
Como o Spring Batch escreve um chunk em um banco relacional — o JdbcBatchItemWriter reduzindo N inserts a um único batch JDBC por chunk, as estratégias de binding por parâmetro nomeado vs. posicional, e os writers ORM JpaItemWriter/HibernateItemWriter, além das APIs de builder do Spring Batch 6.0 e da realocação do pacote infrastructure.item.
Como o contrato ItemWriter orientado a chunk do Spring Batch, junto com FlatFileItemWriter, StaxEventItemWriter e MultiResourceItemWriter, transforma objetos de domínio em saída delimitada, de largura fixa, XML e em conjuntos de arquivos rotativos, além dos builders modernos equivalentes e da realocação de pacote do 6.0.
Como o Spring Batch encaixa entradas fora do padrão em um step de chunks (reaproveitando um método de bean existente com ItemReaderAdapter, consumindo uma fila com JmsItemReader e escrevendo à mão um ItemReader customizado tornado reiniciável via ItemStream), e como essas classes foram movidas para os pacotes org.springframework.batch.infrastructure.item.* no Spring Batch 6.0.
Como o Spring Batch lê linhas de bancos relacionais em fluxo com item readers baseados em cursor e em paginação sobre JDBC e ORM, e como as APIs de builder atuais e os pacotes realocados diferem da configuração XML do livro.
Leia XML grande um fragmento por vez com StaxEventItemReader e um unmarshaller do Spring OXM, e processe um conjunto ordenado de arquivos como um único fluxo contínuo de itens com MultiResourceItemReader.
Como o contrato ItemReader do Spring Batch e o FlatFileItemReader transformam registros de arquivos delimitados, de largura fixa, multilinha, heterogêneos e JSON em objetos de domínio, e os equivalentes modernos com builders e JsonItemReader da configuração XML do livro.
Como parar um job do Spring Batch de forma limpa, de fora como operador com JobOperator.stop e de dentro de um step como desenvolvedor com StepExecution.setTerminateOnly, para que o job pare na próxima fronteira de chunk com segurança transacional e termine em um estado STOPPED reiniciável, e como essas APIs mudaram no Spring Batch 6.0, em que o JobOperator (que estende JobLauncher) é a API e as chamadas stop(long)/getRunningExecutions do livro estão depreciadas para remoção.
Como embutir o Spring Batch no contexto Spring de uma aplicação web mantém um ambiente de batch residente e aquecido (evitando uma JVM nova por job), e como um controller Spring MVC lança jobs sob demanda via HTTP de forma assíncrona, uma configuração feita à mão que o Spring Boot agora autoconfigura, com o JobOperator substituindo o depreciado JobLauncher.
Como as entradas de crontab do cron disparam o CommandLineJobRunner como um processo novo do sistema operacional a cada agendamento, como o suporte @Scheduled/TaskScheduler do Spring oferece uma alternativa in-process com opções fixedRate/fixedDelay/cron desde o Spring 3.0, e por que o Kubernetes CronJob substituiu em grande parte o crontab bruto como modelo de deploy para o mesmo padrão de disparar um processo batch.
Como o CommandLineJobRunner lança um job como um processo java -classpath comum para agendamento no estilo cron (arquivo de configuração Spring, nome do job, job parameters tipados e um ExitCodeMapper que converte o exit status do job em código de saída do shell), e por que ele está depreciado desde o Spring Batch 6.0 em favor do CommandLineJobOperator, que entende de operações.
Como o único método run(Job, JobParameters) da interface JobLauncher inicia uma execução de job, por que o lançamento padrão é síncrono e bloqueia a thread que chamou até o job terminar, como fornecer um TaskExecutor o torna assíncrono, e como JobLauncher/SimpleJobLauncher/TaskExecutorJobLauncher foram todos depreciados desde o Spring Batch 6.0 em favor de JobOperator/TaskExecutorJobOperator.
Como o vocabulário XML do Spring Batch reaproveita o mecanismo de herança de beans abstract/parent do Spring puro para permitir que a definição de um job ou step herde e sobrescreva os atributos de outra, como a flag merge="true" combina em vez de substituir a lista de listeners de um parent, e por que a configuração Java não tem um equivalente direto — a reutilização ali é conseguida extraindo configuração compartilhada em métodos Java comuns em vez de uma palavra-chave dedicada de herança.
Como as interfaces JobExecutionListener/StepExecutionListener/ChunkListener e as de nível de item ItemReadListener/ItemProcessListener/ItemWriteListener/SkipListener permitem encaixar lógica de notificação e tratamento de erros no ciclo de vida de um job sem tocar no reader/processor/writer, e como anotações no estilo @BeforeStep/@AfterStep oferecem os mesmos ganchos em um POJO comum em vez de uma implementação de interface.
Como o escopo de bean customizado StepScope do Spring Batch adia a criação do bean até o step de fato começar, e como expressões SpEL sobre jobParameters/jobExecutionContext/stepExecutionContext permitem que um reader, writer ou tasklet receba um valor conhecido só no lançamento (como o nome de um arquivo de entrada), em vez de deixá-lo fixo na configuração.
Como os atributos XML <batch:job-repository> do livro (data-source, transaction-manager, isolation-level-for-create, table-prefix, max-varchar-length, lob-handler) configuram a única implementação de JobRepository que o Spring Batch traz, o SimpleJobRepository, e como esses mesmos atributos correspondem ao @EnableJdbcJobRepository de hoje, incluindo por que isolation-level-for-create usa SERIALIZABLE por padrão como proteção contra lançar a mesma job instance duas vezes a partir de nós diferentes.
Como os atributos XML de chunk/tasklet do livro (skip-limit, retry-policy, cache-capacity, transaction-attributes, no-rollback-exception-classes) correspondem à configuração Java: primeiro ao FaultTolerantStepBuilder, hoje depreciado, e, a partir do Spring Batch 6.0, ao retryPolicy()/skipPolicy() baseado em objetos de política do ChunkOrientedStepBuilder, construído sobre o retry nativo do core do Spring Framework em vez da biblioteca Spring Retry.
Como os atributos XML de job/step do livro (restartable, incrementer, validator, next, parent/abstract) correspondem aos métodos preventRestart()/incrementer()/validator()/next() do JobBuilder, e por que a configuração Java não precisa de um equivalente à herança parent/abstract do XML.
Como um JobExecutionDecider roteia o fluxo de um job com base no resultado de um step, como a identidade de uma JobInstance é derivada do job mais seus JobParameters identificadores, e por que o JobLauncher está depreciado no Spring Batch 6.0 em favor do JobOperator.
Como funcionam os componentes de infraestrutura JobLauncher e JobRepository, por que job repositories persistentes ou em memória trocam monitoramento e reinício por overhead, e como um job é modelado como uma sequência de steps com fluxo de controle não linear opcional. Observação: o JobLauncher está depreciado em favor do JobOperator desde o Spring Batch 6.0.
Como funcionam o modelo Job/Step/JobInstance/JobExecution/StepExecution do Spring Batch e o processamento orientado a chunks com ItemReader/ItemProcessor/ItemWriter, e como a configuração Java com JobBuilder/StepBuilder substituiu o namespace XML, hoje depreciado.