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

Comportamento bate somente após adicionar e remover o projeto do WildFly

Olá! Tudo bem?

Aqui fiz o seguinte teste:

  1. No AgendamentoEmailServico, no médo "alterar", acrescentei a anotação "@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)", executei, e o comportamento foi igual ao demonstrado no vídeo;
  2. Retirei a anotação "@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)", executei, porém o mesmo comportamento permaneceu (alterando alguns registros e outros não), o que foi diferente do que apareceu no vídeo;
  3. Então fiz um Clean/Project, e um Maven/Update, executei novamente, e permaneceu o mesmo comportamento (como se a anotação "@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)" ainda estivesse lá);
  4. Então, como último teste, fui no WildFly, removi o projeto, e adicionei-o novamente, executando-o em seguida, e dessa vez funcionou normalmente, da mesma forma que está demonstrado no vídeo.

Achei curioso esse comportamento, e gostaria de entender o motivo.

Desde já, muito obrigado! :D

3 respostas

Apenas como observação, após a primeira remoção e adição do projeto no WildFly, para os testes seguintes, não foi mais necessário fazer o mesmo procedimento. A simples alteração do código, stop e start do wildfly, as alterações do código foram refletidas para o runtime.

Mesmo assim, se possível, gostaria de ter alguma ideia do motivo desse comportamento, porque acho que é o tipo de coisa que, depois de algumas madrugadas de codificação, nos faz deletar e reescrever uma boa quantidade de código, achando que é algum problema de framework ou alguma falha na configuração ou no nosso próprio código. kkkkkkkkk..

Desde já, muito obrigado!

Oi, Everton. Tudo bom? Acontece que a alteração feita no seu código na IDE não reflete no projeto que está deployado no servidor. Por isso quando você faz a alteração, você precisa "redeployar" a aplicação e isso é feito dando o start/stop no servidor (De forma transparente ele vai publicar o artefato alterado para nós). Você consegue fazer configurações para que seja feito um "hot deploy" e assim funcionaria como frameworks iguais ao quarkus e spring boot, que a cada alteração é feito um deploy de forma automática, porém nem sempre é uma atividade muito fácil.

solução!

Olá João! Tudo bem? Muito obrigado pela resposta! :D

Minhas recordações me dizem que eu parei o servidor antes de fazer as alterações, e iniciei logo em seguida. Tenho o costume de fazer isso, de forma que já é quase automático. Não coloquei nas descrições do teste porque achei que estaria implícito.

De qualquer forma, como seres humanos cometem erros, pensei: é, pode ser que eu tenha esquecido, a final, existem exceções... kkkkkkk. Então testei novamente o passo 4, fazendo uma pequena alteração (colocando um System.out.println no job), removendo o projeto do servidor sem pará-lo, e em seguida colocando o projeto novamente no servidor.

Para minha surpresa, funcionou normalmente. A alteração no código foi atualizada no servidor e o resultado apareceu no console.

Acho que, por enquanto, talvez possamos classificar o que houve como uma grande exceção. kkkkkkkkkk