Dúvida no Ex. 6 da Aula 5 - Integração com outras tecnologias: Maven, Spring e EJB

Oi Ricardo,

qual problema exatamente está acontecendo?

Lendo o artigo, me parece ser mais relacionado com o ClassLoader do que com CDI.

Outra duvida, qual é a razão de dividir as funcionalidades em vários JAR/WAR?

abs

Olá nico, acho que ainda não resolveram o tal do BUG(https://issues.jboss.org/browse/CDI-129).

Quanto a necessidade de dividir em vários ejbs e vários wars é que são projetos completamente distintos, mas que entretando tem interdependência. Somos um Tribunal aqui, então por exemplo temos um sistema que é responsável pelo cadastro dos gestores, órgãos,mandatos, etc..., temos o sistema de cadastro de processos, onde temos os processos,andamentos julgamentes mas os processos estão ligados aos órgãos e aos gestores, o mesmo acontece com as licitações, que dependem dos órgãos, quando empacoto tudo dentro de um EAR eu consigo usar as entidades e os beans de sessão de um projeto ejb em outro projeto ejb ou então session beans de projetos ejb diferentes em um war, não preciso reescrever todas as entitys, não sei se fui claro

Oi Ricardo,

Seguem os meu dois centavos :)

A dúvida que tenho é, quanto realmente vale fazer essa separação em módulos já que vc continua com uma unidade de deploy. Para mim valeria se esses JARs tbm seriam utilizados em outros projetos. Ou seja, se tivesse uma reutilização dos módulos em aplicações diferentes.

Outro ponto é que vc organizou os JARs baseadas nas suas camadas, separado em front (gestores.war) e back-end (gestores_server.jar). Quando há uma mudança em uma funcionalidades, por exemplo nos gestores, provável que vc precise mexer nos dois módulos, pois há esse acoplamento forte.

Em geral, a modularização no mundo Java é algo muito mal resolvida, e traz esse problema que vc está enfrentando com CDI. Java Runtime não consegui determinar dependências entre módulos que causa o famoso JAR Hell.

São apenas considerações e claro, tudo precisa ser avaliado dentro de seu contexto!

abs