[Prévia] [Próxima] [Prévia por assunto] [Próxima por assunto]
[Índice cronológico] [Índice de assunto]

Re: Novamente ClassCastException



Olá Daniel.

On 6/25/06, Daniel Creão <ldaugusto@xxxxxxxxx> wrote:
Eu havia implantado o servidor e como no JNDIView via

 +- jbossws-client (class: org.jnp.interfaces.NamingContext)
 |   +- service (class: org.jnp.interfaces.NamingContext)
 |   |   +- wsvideorental (class: org.jboss.ws.jaxrpc.ServiceReferenceable)
OK, isso quer dizer que as coisas aparentemente estão corretas do lado servidor.

achava que estava tudo certo, mas hj qnd fiz o client e coloquei pra
rodar só tomo

java.lang.ClassCastException: javax.naming.Reference
       at ClienteFachadaWS.main(ClienteFachadaWS.java:14)

quando faço
VideoRentalStoreService service = (VideoRentalStoreService)
                                               ic.lookup("java:comp/env/service/wsvideorental");
O que o JBoss coloca no JNDI não é na verdade um stub para o seu web
serviece, mas sim uma instância de javax.naming.Reference. Quando você
faz o lookup no cliente, o JBoss tenta achar no classpath uma fábrica
(object factory) que "transforme" esse Reference num stub para o seu
web service. Quem faz isso é a classe
org.jboss.ws.jaxrpc.ServiceObjectFactory, que está no
jbossws14-client.jar. Ou seja, se esta classe estiver no seu
classpath, o JBoss gera um stub e retorna tal stub para o seu cliente.

Já se tal fábrica não for encontrada no classpath do seu cliente, o
lookup retorna uma Reference mesmo (ao invés de um stub), e daí claro,
quando você tenta fazer um cast para VideoRentalStoreService ocorre um
ClassCastException. Desse modo, esse erro indica que está faltando
pelo menos um .jar (provavelmente o jbossws14-client.jar) no seu
classpath.

Olhei os outros emails da lista e chequei meu classpath: quando
adiciono o resto dos jars listados, acontece o erro de
serialVersionUID, mas minha jdk é a 1.5.0_06 e não a 1.6! Porque isso
acontece?
O que acontece é o seguinte: as versões (binárias, isto é, os .class)
de javax.xml.namespace.QName são diferentes do lado cliente e
servidor. Ou seja, o servidor vai seriar uma instância de
javax.xml.namespace.QName, e quando o cliente tentar "deseriar" essa
instância vai ocorrer um erro, pois o cliente só sabe "deseriar" a
versão dele de javax.xml.namespace.QName (que é diferente da versão do
servidor). A solução, nesse caso, é fazer com que os lados cliente e
servidor usem a mesma versão da classe javax.xml.namespace.QName. Isso
é feito através de um mecanismo chamado endorsed:

http://java.sun.com/j2se/1.4.2/docs/guide/standards/

Ou seja, adicionando essa linha ao comando que executa o seu cliente:

-Djava.endorsed.dirs=$JBOSS_HOME/lib/endorsed

vai dizer a JVM: use as classes que estão em $JBOSS_HOME/lib/endorsed
ao invés das classes que estão no JDK. O JBoss faz isso do lado
servidor, quando você roda o script run.[sh|bat]. Se seu cliente
possui um javax.xml.namespace.QName diferente do que é encontrado em
$JBOSS_HOME/lib/endorsed/xml-apis.jar, você deve adicionar essa linha
ao seu cliente (pois do contrário as versões do cliente e servidor
serão diferentes). O estranho é que eu estou rodando o JDK 1.5.0_06, e
eu não preciso habilitar o mecanismo de "endorsed".

Só uma coisa: você diz "quando adiciono o resto dos jars listados".
Então presumo que você tem outros jars no seu classpath. Eu acredito
que você tem algum .jar de fora do JBoss no classpath do seu cliente
que possui uma versão mais nova de javax.xml.namespace.QName.
Lembre-se, você não precisa (e nem deveria, a menos que tenha certeza
do porque) ter nenhum .jar que não seja do JBoss no classpath do seu
cliente. Acredito que verificando isso seu problema deve desaparecer.

Tb percebi que não tinha lido um email onde o colega cita que em
http://localhost:8080/wsvideorental/services ele consegue ver os
serviços, mas aqui o que vejo é "The requested resource
(/wsvideorental/services) is not available." Mas eu consigo acessar o
WSDL via browser e no console do jboss não tenho nenhum erro:
O problema que você está tendo é do lado cliente. Se você consegue ver
uma entrada no JNDI e acessar o WSDL do web service, então seu lado
servidor muito provavelmente está correto. Dê uma checada no classpath
do seu cliente.

Se o problema persistir, por favor volte a escrever.

[]'s

--
Ivan Neto