----- Original Message ----- From: "Hashimoto, Mike" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>
> You have set the classpath to the "current directory" and you are invoking > the sample from the addressbook directory. When you say '.', Java is > looking for samples/addressbook/Address.class from where you currently are > (which is two directory levels too low). Just 'cd' back to the webapps/soap > directory and re-issue your command and all should be good. > Hi Mike and others, Thank you, but I'm afraid that didn't solve the problem. (I tried that also before I sent my first mail, I just didn't mention all my desperate attemps :-| ). So here's what I did: -------------------------------------- jerry@ws93:/usr/share/tomcat/webapps/soap/samples/addressbook$ cd .. jerry@ws93:/usr/share/tomcat/webapps/soap/samples$ cd .. jerry@ws93:/usr/share/tomcat/webapps/soap$ java samples.addressbook.GetAddress http://localhost:8080/soap/servlet/rpcrouter "John B. Good" Generated fault: Fault Code = SOAP-ENV:Client Fault String = Deployment error in SOAP service 'urn:AddressFetcher': class name 'samples.addressbook.Address' could not be resolved: samples.addressbook.Address jerry@ws93:/usr/share/tomcat/webapps/soap$ java -cp . samples.addressbook.GetAddress http://localhost:8080/soap/servlet/rpcrouter "John B. Good" Generated fault: Fault Code = SOAP-ENV:Client Fault String = Deployment error in SOAP service 'urn:AddressFetcher': class name 'samples.addressbook.Address' could not be resolved: samples.addressbook.Address jerry@ws93:/usr/share/tomcat/webapps/soap$ java -cp .:./samples/addressbook samples.addressbook.GetAddress http://localhost:8080/soap/servlet/rpcrouter "John B. Good" Generated fault: Fault Code = SOAP-ENV:Client Fault String = Deployment error in SOAP service 'urn:AddressFetcher': class name 'samples.addressbook.Address' could not be resolved: samples.addressbook.Address -------------------------------------- So, none of those "good tries" worked. :-). Problem persists. This is related to CLASSPATH, but where exactly does the problem lie? Or is it in the service deployment somehow (as the Fault String insists)? Regards, Jerry
