You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Jim Azeltine <ja...@sbcglobal.net> on 2005/12/14 17:21:47 UTC
Problem with production deployment of Eclipse developed WS client
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 classes 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 correct 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
Re: Problem with production deployment of Eclipse developed WS client
Posted by Jim Azeltine <ja...@sbcglobal.net>.
Thanks! That link provided the final piece of the puzzle, adding the -security option when starting up Tomcat. I had already modified the catalina.properties file to add the socket permission, I could not understand why it didn't make a difference. I just didn't see anywhere that you needed to add the security option. The only problem now is that the application for which the server was installed on the box no longer works once the security is enabled! >8/
All I have to do now is get the correct values for all the security values involved with the existing apps, and get it to work. I am sure that will be really fun... =:-}
Jim Azeltine
Sr. Software Engineer
SAIC
Jason Cwik <bi...@gmail.com> wrote:
Here's a page on how to pass tomcat a security policy file: http://tomcat.apache.org/tomcat-4.1-doc/security-manager-howto.html
On 12/15/05, Jim Azeltine <ja...@sbcglobal.net> wrote: I would agree, but the issue is that I can access the service from the command line if I include the parameter to utilize the contents of the property file that grants access to all ports above 1099. That tells me that the RMI registry is accepting requests, and the service is registered and accessible. The problem seems to be getting access to the dynamically allocated outgoing RMI port. It has been a few weeks since I last saw the exception, it may have included "access denied". I am in the process of reconstructing the problem again.
Jim Azeltine
Sr. Software Engineer
SAIC
Jason Cwik < billbrasky66@gmail.com> wrote:
"Connection Refused" usually indicates that you DID get a socket, but nobody was listening on the other side. Or, a firewall is blocking the port. If it's a security problem you'd get a security exception.
On 12/15/05, Jim Azeltine < jazeltine@sbcglobal.net> wrote: 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 s ay 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 c ode 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 < davanum@gmail.com> 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
> SAIC
>
>
> 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 lot s 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 getEn dpoint() 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/
Re: Problem with production deployment of Eclipse developed WS client
Posted by Jason Cwik <bi...@gmail.com>.
Here's a page on how to pass tomcat a security policy file:
http://tomcat.apache.org/tomcat-4.1-doc/security-manager-howto.html
On 12/15/05, Jim Azeltine <ja...@sbcglobal.net> wrote:
>
> I would agree, but the issue is that I can access the service from the
> command line if I include the parameter to utilize the contents of the
> property file that grants access to all ports above 1099. That tells me that
> the RMI registry is accepting requests, and the service is registered and
> accessible. The problem seems to be getting access to the dynamically
> allocated outgoing RMI port. It has been a few weeks since I last saw the
> exception, it may have included "access denied". I am in the process of
> reconstructing the problem again.
>
> Jim Azeltine
> Sr. Software Engineer
> SAIC
> *Jason Cwik <bi...@gmail.com>* wrote:
>
> "Connection Refused" usually indicates that you DID get a socket, but
> nobody was listening on the other side. Or, a firewall is blocking the
> port. If it's a security problem you'd get a security exception.
>
> On 12/15/05, Jim Azeltine <ja...@sbcglobal.net> wrote:
> >
> > 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 s ay 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 c ode 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 < davanum@gmail.com>* 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
> > > SAIC
> > >
> > >
> > *
> > ***> 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 lot s 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 getEn dpoint() 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/ <http://wso2.com/%0A+blogs/>
> > >
> > >
> > >
> >
> >
> > --
> > Davanum Srinivas : http://wso2.com/blogs/
> > *
> >
> >
> >
>
>
Re: Problem with production deployment of Eclipse developed WS client
Posted by Jim Azeltine <ja...@sbcglobal.net>.
I would agree, but the issue is that I can access the service from the command line if I include the parameter to utilize the contents of the property file that grants access to all ports above 1099. That tells me that the RMI registry is accepting requests, and the service is registered and accessible. The problem seems to be getting access to the dynamically allocated outgoing RMI port. It has been a few weeks since I last saw the exception, it may have included "access denied". I am in the process of reconstructing the problem again.
Jim Azeltine
Sr. Software Engineer
SAIC
Jason Cwik <bi...@gmail.com> wrote:
"Connection Refused" usually indicates that you DID get a socket, but nobody was listening on the other side. Or, a firewall is blocking the port. If it's a security problem you'd get a security exception.
On 12/15/05, Jim Azeltine <ja...@sbcglobal.net> wrote: 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 < davanum@gmail.com> 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
> SAIC
>
>
> 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
> > 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/
Re: Problem with production deployment of Eclipse developed WS client
Posted by Jason Cwik <bi...@gmail.com>.
"Connection Refused" usually indicates that you DID get a socket, but nobody
was listening on the other side. Or, a firewall is blocking the port. If
it's a security problem you'd get a security exception.
On 12/15/05, Jim Azeltine <ja...@sbcglobal.net> wrote:
>
> 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 <da...@gmail.com>* 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
> > SAIC
> >
> >
> **> 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
> > > 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/
> *
>
>
>
Re: Problem with production deployment of Eclipse developed WS client
Posted by Jim Azeltine <ja...@sbcglobal.net>.
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 <da...@gmail.com> 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
> SAIC
>
>
> 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
> > 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 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 : http://wso2.com/blogs/
>
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: Problem with production deployment of Eclipse developed WS client
Posted by Davanum Srinivas <da...@gmail.com>.
things get "stuck"? you mean the original service is not undeployed?
what are the symptoms?
-- dims
On 12/15/05, Jim Azeltine <ja...@sbcglobal.net> 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 <da...@gmail.com> 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 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 : http://wso2.com/blogs/
>
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: Problem with production deployment of Eclipse developed WS client
Posted by Jason Cwik <bi...@gmail.com>.
I think it's usually a good idea anyways to put the endpoint address in a
property somewhere, since people tend to move and rename servers...
On 12/14/05, Davanum Srinivas <da...@gmail.com> wrote:
>
> check the WSDL you used to generate the original client code :) look
> for soap:address
>
> -- dims
>
> On 12/14/05, Jim Azeltine <ja...@sbcglobal.net> 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 classes 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 : http://wso2.com/blogs/
>
Re: Problem with production deployment of Eclipse developed WS client
Posted by Jim Azeltine <ja...@sbcglobal.net>.
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 <da...@gmail.com> 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 classes 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 : http://wso2.com/blogs/
Re: Problem with production deployment of Eclipse developed WS client
Posted by Davanum Srinivas <da...@gmail.com>.
check the WSDL you used to generate the original client code :) look
for soap:address
-- dims
On 12/14/05, Jim Azeltine <ja...@sbcglobal.net> 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 classes 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 : http://wso2.com/blogs/