axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Azeltine <>
Subject Re: Problem with production deployment of Eclipse developed WS client
Date Thu, 15 Dec 2005 20:06:13 GMT
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
  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
Davanum Srinivas <> wrote:
  things get "stuck"? you mean the original service is not undeployed?
what are the symptoms?

-- dims

On 12/15/05, Jim Azeltine 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
> Davanum Srinivas 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
> > 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 proxy 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 :

Davanum Srinivas :


View raw message