I modified the original service to return different data. I initially tried just overwriting the classes, but that did not do it. The service returned the original data (which was hardcoded for testing).
Next, I undeployed the service, verified that it was no longer available, and overwrote the classes. I redeployed the service. It still returned the original data.
Then I took a more extreme step, I removed the directory that held the classes that provide the service, and it still worked! I can only assume from all this that it is being cached, I just need to keep that in mind now.
I should also say that I am developing all this with Eclipse 3.1 with the WTP plugins, and deploying it to Tomcat on the Sun server after transport via FTP. I am hoping at some point to get it set up so I can do the deployment to the Sun server from Eclipse, but that is for another day (I have experience with remote deployment with Ant, just not under
Eclipse).
I know now that the original problem was caused somehow because the app was generated with Eclipse. For some reason, it had included localhost:8080 in there the first time, but with the current deployment, it did not. I do not know what I might have done differently the first time.
The only reason I changed it in the first place is because I am fighting another problem not directly related to Axis. I need to access data on another server that does not have a webserver running. I have an RMI server and process running in that machine, but I cannot seem to get around the "Connection refused" error when the webservice code attempts to access the local RMI port. How does one go about providing SocketPermission for an Axis process like you can from the command line?
Jim Azeltine
Sr. Software Engineer
SAIC
Davanum Srinivas <[EMAIL PROTECTED]> wrote:
things get "stuck"? you mean the original service is not undeployed?
what are the symptoms?
-- dims
On 12/15/05, Jim Azeltine <[EMAIL PROTECTED]>wrote:
> Thanks for the response dims, I know you are a busy guy! 8)
> I actually did that, and it was correct. I have corrected part of the
> problem. It appears that in an Apache/Tomcat environment running on Sun (I
> forgot to mention it is Axis 1.2.1 I am using), things get "stuck". I had to
> undeploy the service, rip the entire client out, restart Apache & Tomcat,
> upload everything again, perform deployment, restart Apache & Tomcat AGAIN.
> Now the endpoint address is correct. The original webservice class is still
> "stuck" in there somewhere though. I even deleted the entire directory tree
> that holds the POJO class, and it still works. How is that possible? The> only assumption I can make is that the JSP compiler must be putting a copy
> of it somewhere, and it is not getting updated.
>
> Jim Azeltine
> Sr. Software Engineer
> SAIC
>
>
> Davanum Srinivas <[EMAIL PROTECTED]>wrote:
> check the WSDL you used to generate the original client code :) look
> for soap:address
>
> -- dims
>
> On 12/14/05, Jim Azeltine wrote:
> > I have made lots of good progress with web services thanks to this list. I
> > have Eclipse 3.1 with the WTP plugins installed and working. Using Tomcat
> > 5.0.2.8 and JDK 1.4.2_08 in my development workstation. The roadblock at
> > this point is that the target production environment is on server running
> > Solaris 5.9, Apache 1.3, and Tomcat 4.1.29, and this server is behind a
> > firewall. I am accessing the client webpage from inside the firewall as I
> am
> > connected via VPN.
> > When a functional (in the development environment) Eclipse generated
> client
> > is deployed to the server, it does not work as expected. I successfully
> > deployed the service, and installed the client class es and the jsp files
> in
> > the server.
> > The client page will come up, the getEndpoint() method returns the wrong
> > value! The Tomcat instance is set up to listen on port 8921, but the
> server
> > and port are wrong in the response, localhost:8080 instead of the corr ect
> > server and port. This initially made me think the service did not work, as
> I
> > got "ConnectException: Connection refused". Once I realized the endpoint
> was
> > wrong and used the setEndpoint() method to set the correct value, the
> > service works. So the question is why does the following call in the init
> > method of the p roxy class return the wrong value?
> > _endpoint =
> >
> (String)((javax.xml.rpc.Stub)testClass)._getProperty("javax.xml.rpc.service.endpoint.address");
> >
> > Jim Azeltine
> > Sr. Software Engineer
> > SAIC
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
