I’ve followed the guide to setting up my dts to publish locally on my app server but after configuring server.xml and deliver-servers.xml port 9980 still resolves to the tomcat welcome page. Any ideas of what I missed or did incorrectly?
Hi Scott,
First, be sure to clear your browser’s cache after re-configuring this. You may simply have the Tomcat welcome page cached at that address from before you set this up.
If that doesn’t help, this must be a host mapping issue. Whatever host or IP address you defined in the server.xml’s host property needs to be the host or IP address you use to connect to the Tomcat server, or else you will see the default Tomcat welcome page.
For example, if you map the server’s hostname to your site’s published appBase within your Host node, but then connect to the server using it’s IP address, you’ll see the Tomcat welcome page. You may want to reference step 2 to be sure you’re using the correct host / IP:
After clearing the cache it still returns the tomcat welcome page. I looked through the reference and checked my server.xml and it looks to be correct.
Hey Scott,
Would you be able to share your host configuration settings in your server.xml file with me (if it contains information you want to keep private like your system’s IP, we can take this offline)? If so, please copy all content starting with your very first element down to the end of the file, and paste it on here between Code and Pre tags, like so:
Content from server.xml goes here.
Thanks!
<!-- SingleSignOn valve, share authentication between web applications <br />
Documentation at: /docs/config/valve.html --> <br>
<!-- <br />
<Valve className="org.apache.catalina.authenticator.SingleSignOn" /> <br />
--> <br><br>
<!-- Access log processes all example. <br />
Documentation at: /docs/config/valve.html --> <br>
<!-- <br />
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
<br />
prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/> <br />
--> <br><br>
</host>
<host name="DT00WB52" appbase="www.ksdot.orgapps"> <br>
</host>
<valve classname="com.percussion.tomcat.valves.PSSimpleRedirectorValve" targethost="localhost" servicenames="perc-form-processor,perc-common-ui,perc-metadata-services,perc-comments-services,feeds,perc-caching,perc-membership-services,perc-generickey-services,perc-polls-services,perc-thirdparty-services"></valve>
Scott,
Your config looks fine. You’re connecting using http://DT00WB52:9980, correct?
Assuming so, an initial mis-configuration may be getting stored in Tomcat’s temp files. To clear these out, delete all files within these three directories:
[dts_root]/Deployment/Server/conf/Catalina
[dts_root]/Deployment/Server/temp
[dts_root]/Deployment/Server/work
Once you’ve done so, shut down and then start back up your Tomcat server, then clear your cache and access http://DT00WB52:9980 once again. Let me know if this makes any difference.
Yea that did make a difference, haha now I get a ‘Google could not connect to dt00wb52:9980’ message.
Hah not quite what we were looking for. Trying using Task Manager (view processes from all users) to manually end all java.exe processes, and then start the full Percussion service back up. The Tomcat process should start up with Percussion (assuming it’s installed within the Percussion filetree).
It is installed with Percussion in the same path, but it did not start up after the Percussion Service started.
That is very weird. How have you started the embedded Tomcat in the past? You do have a TomcatStartup.bat file in the Percussion installation root, correct? Also, can you confirm that http://localhost:9980 loaded from a browser from within the actual app server doesn’t load the Tomcat welcome screen?
I have never had to start it manually. Yes there is a TomcatStartup and Shutdown batch file in the Percussion root. And now the Tomcat welcome screen does not load on the application server.
Strange stuff. I’m going to open a support ticket so that I can take a peek at your log files. Please check your inbox in one second.
Sent.
Thanks! I’ll be taking a look at this shortly.
To close out this thread for the rest of the Community, there were a number of minor issues with their DTS Tomcat’s server.xml file leading to port conflicts within the system. Simply swapping in a server.xml file from an out-of-box DTS deployment and working from there corrected the problem.