Solucionado (ver solução)
Solucionado
(ver solução)
3
respostas

Erro de importação do spring security

Boa tarde.

Ao seguir os passos desta aula (vídeo 2 da aula de login/logout do curso de Spring MVC II), o console do eclipse não deixa iniciar o server por causa de erros após a atualização do pom.xml (incluindo as 4 dependências do spring security).

Eu corrigi um erro semelhante (neste mesmo curso, com a versão do spring-context) a este apenas alterando a versão. Dúvida (e espero que esta pergunta me ajude a saber o que fazer quando isso acontecer novamente: Como posso saber qual versão de dependências eu posso atualizar? O curso de Maven ensina isso ou tem alguma dica rápida que vocês podem me dar?)

Meu pom.xml: https://gist.github.com/guilhermewolke/604e1217a07b22f934794e8d26c294ad

Minha exception: https://gist.github.com/guilhermewolke/06cdc3daced8996a381899dfd61598b2

Gratidão.

3 respostas

Fala Guilherme, tudo bem ?

"Como posso saber qual versão de dependências eu posso atualizar? O curso de Maven ensina isso ou tem alguma dica rápida que vocês podem me dar?"

Aqui temos um caso sensível. O maven em si oferece toda a infraestrutura necessária para a gestão das dependências, mas não tem (que eu saiba =/) uma forma direta para prever esse tipo de conflito com versões de jars que possuem essas dependências externas. Em alguns casos as documentações de certas libs/frameworks, em suas determinadas versões, deixam claro a necessidade de seguir versões específicas de outras libs cujo trabalho é dependente.

Quando esse tipo de coisa acontece (NoSuchMethodError: org.springframework.util.AntPathMatcher.setCaseSensitive) em geral, acaba sendo de nossa responsabilidade buscar a causa do problema/conflito nas documentações das libs que estamos usando.

Por exemplo, pesquisando por aqui, vi que o referido método (AntPathMatcher.setCaseSensitive) só está presente a partir da versão 4.2.x do spring-core, sendo que no pom.xml a versão do spring mvc (4.1) também trará a mesma versão do core

Você pode usar a visualização Dependency Hierarchy do pom.xml para ver as dependências resolvidas. Talvez seja o máximo de suporte que a IDE com o plugin do maven vai te dar

Exemplo: dependencies

Se dermos uma olhada nas Javadocs veremos a diferença:

Talvez atualizando o spring mvc para a versão 4.2.X resolva esse problema. E lembre sempre de dar um Clique direito no projeto > Maven > Update Project > Force Update of Snapshots/Releases para reconstruir as dependências evitando problemas após alterar o pom.xml. Agora sempre fica o mistério do por que alguma biblioteca passou a chamar este método mais recente causando o conflito. Talvez até a atualização da versão do spring-context tenha gerado isso.

Enfim.. Espero ter ajudado

Abraço!

Isso resolveu, eu dei "clean" no server, e no projeto eu dei "Maven > Update Project > Force Update of Snapshots/Releases".

Dúvida (antes de dar como solucionado); Qual a diferença entre esse "Force update" e o "clean"? Sei que são coisas distintas mas só funcionou quando dei o clean no tomcat antes do "force update" (eu tinha dado esse force update antes e não surtiu efeito, aí tentei novamente com o clean antes).

solução!

Fala Guilherme, blz ?

O Clean ou clean working directory no Server serve para ajustarmos o estado do projeto que está deployado na pasta do servidor com o estado do projeto de acordo com a pasta no workspace (os arquivos que você está editando, por exemplo). O servidor vai descartar o deploy antigo e implantar tudo novamente com o estado atual do workspace.

O Maven > Update Project > Force update já se refere a atualização do projeto no workspace. O Maven vai fazer um novo build e forçar a reconstrução do classpath do projeto "religando" as dependências com os jars que ele mantém no seu repositório local (pasta .m2 na sua máquina). O que as vezes realmente é suficiente pra resolver alguns conflitos.

PS: Pessoalmente, as vezes, removo o projeto do server, aplico clean e clean server working directory no servidor, aplico clean no projeto (ou maven update project pra forçar, principalmente se algo foi alterado no pom.xml como dependência do projeto, etc) > aí adiciono o projeto novamente ao server, dou publish no server (enquanto monitoro a pasta de instalação onde o server deixa as apps pra ver se a pasta foi mesmo recriada), e por fim subo o server. Em casos muito críticos (ou onde tudo parece bruxaria), pode ajudar a resolver problemas de deploy, que as vezes são causados pelo próprio plugin do maven pro eclipse.

Espero ter ajudado. Abraço!