If you support code for multiple java application servers, you might eventually encounter a file named:
JBoss uses this file to control the path of the web application, whereas Tomcat generally uses the filename of the WAR itself.
Usually, the contents are pretty sparse, you might consider adding one to your projects should you ever wish to deploy them on JBoss:
NOTE: There are several other attributes that can find their way into this file for JBoss, notably security configuration, like JAAS.
WARNING: Unfortunately, I’ve tried to add a simple
DOCTYPE jboss-web and XML preamble to this, file to make it validate, but the server (JBoss 5.1.x) fails to recognize them.
There are a few steps that I generally take to setup a new Tomcat server instance, this enables the following:
- The manager console
- HTTP compression
- UTF-8 encoding
- tomcat-users.xml – add to bottom:
<user username="tomcat" password="s3cr3t" roles="manager-gui"/>
server.xml – add compression and URIEncoding, change port if desired:
<Connector port="8080" protocol="HTTP/1.1"
redirectPort="8443" compression="on" URIEncoding="UTF-8" />
- server.xml – relocate webapps by adding ../ to appBase
<Host name="localhost" appBase="../webapps"
- Restart your server, on Ubuntu use:
sudo service tomcat7 restart
Best practices for web applications often call for the use of a CDN. Those of you that have worked with YSlow! are likely very accustomed to seeing warnings for this reason. I’ve found that CloudFlare is very easy to setup, and for basic services costs absolutely nothing. In addition to the obvious performance advantages of using a CDN to offload much of your network traffic, it also has the advantage of improved security.
CDN’s work by caching a copy of your static content at several locations around the world, making it closer and faster for your users.
Implementation takes only minutes as it requires that you:
- create a (free) account,
- retrieve your existing DNS values from your current provider,
- determine direct vs. CDN “cloud” routing for each subdomain,
- change your DNS records to point to the CloudFlare DNS servers
Some additional advantages I’ve seen since implementing:
- Site remains available in limited capability to users during server outages or upgrades.
- Simplified network configuration as all requests can be sent outside of the LAN for users local to the servers
- IPv6 dual-stack support