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

Re: [reverbel-sod] Re: Novamente ClassCastException

Oi Daniel.

On 6/26/06, Daniel Creão <ldaugusto@xxxxxxxxx> wrote: 
É, continuo sem entender como minha jdk 1.5 pode tar gerando codigo
1.6, mas com o endorsed e o classpath correto realmente não dá mais
aquele erro, mas agora tenho:

Só uma coisa: seu jdk 1.5 não está gerando código 1.6. O que acontece
é que a versão binária da classe javax.xml.namespace.QName que seu
cliente usa é diferente da versão que o servidor usa. Muito
provavelmente a versão que o seu cliente usa é mais nova que a versão
que o servidor usa.

O que eu estou achando estranho é que mesmo se você colocasse uma
versão mais nova dessa classe (javax.xml.namespace.QName) no
classpath, essa versão mais nova não seria carregada, pois a versão
que vem no JDK tem prioridade. O único modo de fazer uma versão mais
nova (ou mais velha) dessa classe ser carregada pela JVM é usando o
mecanismo endorsed do JDK. Fique atento ao seu IDE, se você estiver
usando algum. Pode ser que ele esteja adicionando parâmetros ao
comando de execução do seu cliente sem que você perceba.

javax.naming.NamingException: Could not dereference object [Root
exception is java.lang.ClassNotFoundException:
serverWS.RentalServiceWS]
        at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1150)
        at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:705)
        at org.jboss.naming.client.java.javaURLContextFactory$EncContextProxy.invoke(javaURLContextFactory.java:135)
        at $Proxy0.lookup(Unknown Source)
        at javax.naming.InitialContext.lookup(InitialContext.java:351)
        at ClienteFachadaWS.main(ClienteFachadaWS.java:15)
Caused by: java.lang.ClassNotFoundException: serverWS.RentalServiceWS
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at org.jboss.ws.jaxrpc.ServiceObjectFactory.getObjectInstance(ServiceObjectFactory.java:264)
        at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
        at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1125)
        at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1142)
        ... 5 more

Ele diz que não acha minha classe que implementa
VideoRentalStoreService, mas é exatamente esse o caminho dela:
serverWS.RentalServiceWS

O problema novamente é o classpath. O diretório onde estão as classes
compiladas do seu EP deve estar no classpath do seu cliente. Por
exemplo, se suas classes estão no diretório "/meu/ep/bin", você deve
adicionar esse diretório ao seu classpath:

export CLASSPATH=os_jars_que_eu_mencionei_em_outro_email:/meu/ep/bin

Dentro do diretório "/meu/ep/bin" deve haver um diretório "serverWS",
e dentro desse deve haver um arquivo RentalServiceWS.class. Você pode
usar um IDE, como o Eclipse, que te permite arrumar o classpath usando
uma interface gráfica.

Se não funcionar ou se tiver qualquer outro problema, escreva novamente.

Bom trabalho!

Alguma idéia do que possa ser (na msg anterior coloquei os xml caso
precise consultar)?

Daniel

On 6/25/06, Ivan Neto <ivanneto@xxxxxxxxx> wrote:
> 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
>


--
[]s
Daniel
___________________________________



--
Ivan Neto