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 AzeltineSr. Software EngineerSAIC Jason Cwik [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 reconst
ructing
the problem again.Jim AzeltineSr. Software EngineerSAIC Jason Cwik [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ser
ver 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 AzeltineSr. Software EngineerSAIC Davanum Srinivas [EMAIL PROTECTED] wrote:things get "stuck"? you mean the original service is not undeployed? what are the symptoms?-- dimsOn 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, &
gt;
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
