Olá pessoal,
Tenho duas aplicações(xxx.ear e yyy.ear) que fazem uso de uma mesma “api” que nada mais é que um .jar, ou seja, cada .ear fica com uma cópia desse .jar (assim como o struts.jar)
O que faço é simplesmente dar um build das aplicações com esse .jar e assim que subo o JBoss tudo fica lindo e maravilhoso, rodando perfeitamente.
Porém, durante o desenvolvimento há a necessidade de fazer outros builds(deploy) e aí começam a aparecer os problemas.
Um deles é o erro java.lang.ClassCastException “Classe que está no .jar” class que ocorre após o deploy do xxx.ear.
O xxx.ear estava rodando e “enxergando” o .jar normalmente, porém após um deploy algo se perdeu.
Alguém já teve problema semelhante ?
Gerar um .jar e distribuir em .ear´s não é a forma ideal de distribuir uma api ?
Agradeço qualquer ajuda,
Rogério
Se você tem um .jar que é utilizado por duas Enterprise Applications, não vejo motivo para distribui-lo dentro de cada .ear.
Eu colocaria no classpath do App. Server e com isso já estaria disponível para todas suas aplicações.
Essa estratégia só não seria útil se você precisa distribuir versões diferentes do seu .jar.
[]'s
Marco Campêlo
A maior parte das aplicações em .jar podem ser distribuídas corretamente em mais de um .ear.
Mas algumas bibliotecas, como o Struts e o Log4J (ou o commons-logging, não tenho certeza), têm alguns problemas com isso. Elas devem ser postas no classpath do application server, devido a problemas com tratamento de classloader etc.
Amigos,
Muito obrigado pelas respostas.
Estou utilizando o .jar no /lib conforme sugestão do Marco Campêlo. Está rolando bem no momento.
Só tenho uma dúvida: Caso haja a necessidade de alteração desse .jar, precisarei reiniciar meu App Server para que o novo .jar fique valendo ?
[]´s
Rogério
Pelo pouco que entendo de App. Server (leia-se WebLogic), não há como fazer reload do que está no ClassPath da JVM sem parar o App. Server (=matar a JVM) e startá-lo novamente (=iniciar a JVM).
Uma Enterprise Application (.ear) ou até mesmo uma Web Application (.war) tem classpath próprio e apenas com um redeploy já é suficiente.
No caso do ClassPath da JVM, não há esse “redeploy”.
[]'s
Marco Campêlo