Java.lang.ClassCastException - não sei a origem dele
16 respostas
boaglio
Gente,
Minha aplicação tem três módulos, todos no mesmo .EAR .
O primeiro módulo já funciona perfeitamente e está em produção.
Estou desenvolvendo o segundo agora, e ao chamar um servlet
do primeiro (que já funciona), recebo a mensagem:
O problema está no seu jsp /conteudo/ct4_prod.jsp. Como você está acessando a classe Produto no jsp?
A classe Produto, só tem em um modulo? Só existe a br.com.apexsystems.model.Produto?
Pergunta idiota, quem sabe ajuda: tem certeza que colocou um objeto Produto com a chave “protudo” na sessão?
boaglio
Eu olhei no código e está correto.
Eu estou conversando com o Rafael pelo ICQ e ele sugeriu colocar
um System.out.println(“request de teste=”+request.getAttribute(“produto”));
pra checar a saida, e ele busca certo:
request de teste=br.com.apexsystems.model.Produto@14b146
Mas ainda assim dá erro
urubatan
verifica se tu tem a classe Produto em mais de um jar, se existir, pode estar ocorrendo algum problema de ClassLoader carregando duas classes diferentes para contextos diferentes.
boaglio
Na realidade é um container só pra essa aplicação, e só tem
um contexto mesmo.
Existe a máquina da produção, que é outro servidor, que
tem essa aplicação com o mesmo contexto.
Lá não dá esse erro.
Paulo_Silveira
Imprima o class loader de cada classe, assim coma a classe de do objeto que esta no request soh para ter certeza. realmente parece algum problema de classlaoding/stubing.
Estava comentando com o Luca agora a pouco em outro Thread (http://www.guj.com.br/forum/viewtopic.php?t=15945).
O arquivo ear e os arquivos jar que estão dentro deste ear têm ClassLoaders diferentes.
Eu acredito que possa existir mais de uma classe Produto em seus jars, e por isso está ocorrendo o ClassCastException.
Dá uma verificada nisso…
no jar onde esta dando pau, ja estou quase desistindo desta possibilidade, mas não ta fazendo muito sentido este problema :-(
antes do BD do guj crashar eu mandei ele testar com == e adivinha? false
com equals tambem vai dar false porque os classloaders nao reescrevem o equals.
louds
Containers bons costumam sobrescrever o toString() dos classloaders pra oferecerem alguma informação útil.
Mas para achar esse tipo de erro o mais fácil é usar o identity hashcode dos objetos em questão, ou ==, como o Paulo sugeriu.
boaglio
Bom, um colega meu (Jailton) sugeriu que eu colocasse tudo
que estivesse no WEB-INF/classes dentro de um .jar e
colocasse esse .jar no WEB-INF/lib .
Parece q a gambiarra funcionou :lol:
Segundo ele , problema de ClassLoaders no Oracle 9iAS
são bem conhecidos…
Paulo_Silveira
Fernando
isso eh simplesmente inaceitavel num container j2ee
eh incrivel como eles conseguem apssar nos testes da sun. comeco a desconfiar.
urubatan
estou me preparando para começar a sofrer com isto
estou iniciando um projeto que vai utilizar o OC4J