- Navios
- 5 de setembro de 2026 às 00:19 UTC
- Autor
- Kamo
- Enviar
- 9b08a73
Minha própria regressão, e a segunda quebra contexto-startup neste serviço hoje: Erro ao criar o bean com o nome 'terminalTicketRegistry': Falha ao instanciar [...TerminalTicketRegistry]: Nenhum construtor padrão encontrado Causado por: **************************** Primavera escolhe um construtor por si só SOMENTE quando uma classe tem exatamente um. Dado dois e nenhum @Autowired ele cai de volta para o padrão de não-argumento. Esta aula tem dois construtores durante muito tempo — um público sem pacote-privado levando um Relógio para testes — e estava bem, porque o Retail encontrou o não-arg. Mover os tickets para uma loja compartilhada substituiu que No-arg construtor com um tomando uma dependência, por isso não havia mais nada para Para trás. Nada o apanhou. Compila. Cada unidade teste passa, porque eles chamam o construtor diretamente e nunca exercitar a seleção da Primavera em tudo. E o guarda que existe para exatamente esta forma, ApplicationContextStartsTest, é @Desabled até que haja um Redis para ele, enquanto CI dirige a suite com -DskipTests. Então ele vem com uma catraca, como o @Lazy quebrar fez. **************************** reflete sobre cada classe anotado estereótipo e falha qualquer feijão com dois ou mais construtores onde nenhum é @Autowired e não existe nenhum arg público Regresso — que é precisamente o que a própria Primavera vê. Vermelho verificado contra a árvore quebrada (ele nomeou esta classe e somente esta classe, então nada mais no serviço tem o defeito) e verde após a correção. Suíte completa em uma árvore de trabalho isolada: 2175 testes, 0 falhas.