After consulting the company that hosts our old domain, they answered this: 2.5 Eur/Month for web and email redirection. Since we don't need mail redirection, paying a couple of bucks just to send a couple of HTTP headers seemed much to me, that's why I decided to do it myself.
Setting up Sun Java System Application Server on Solaris 10
First of all, I set up a new sparse and shared-IP zone. At the end of the installation I checked the startup script for the Sun Java System Application Server that ships with Solaris 10. If you need a Java application server, you'd better go and install the latest version. As I'm going to run just one servlet filter, using the bundled server seemed like fine to me.The bundled server is installed in /usr/appserver and isn't either SMF-managed:
$ svcs S84appserv
STATE STIME FMRI
legacy_run Mar_13 lrc:/etc/rc3_d/S84appserv
If you examine the startup script, you'll notice that it looks for domains installed in the /var/appserver/domains directory. Of such domains, this scripts starts those who configured the autostart feature, which is simply an empty file named [domain-dir]/config/autostart.
Creating a domain
To create a domain you need to use the /usr/sbin/asadmin command. In my case, I used the following command:/usr/sbin/asadmin create-domain --domaindir /var/appserver/domains --adminport 4848 --adminuser admin --instanceport 8080 --savemasterpassword=true my-web
- --domaindir /var/appserver/domains is necessary to create the domain in the directory searched by the legacy startup script.
- --adminport and --instanceport are used to configure the ports used respectively by the admin console and the applications you'll deploy in this domain.
- --savemasterpassword, or an equivalent technique, is necessary because the startup script is non interactive and cannot ask you about the master password.
Once the domain was done, I touched the autostart file to trigger the startup of the domain:
$ touch /var/appserver/domains/my-web/config/autostart
You can now start your domain by using the startup script:
# /etc/rc3.d/S84appserv start
To test your installation you can use your favorite browser to connect to the admin console on the port you specified (in this case, 4848) or to view the welcome file (on port 8080).
Creating a redirecting servlet filter
To redirect clients' HTTP requests to the new domains we just need to send a HTTP 301 status code (moved permanently) and the new location in the Location HTTP header. Omitting the boiler plate code of a standard Java Servlet filter, the code is just a two liners:response.setHeader("Location", "http://www.newdomain.es/");
response.setStatus(response.SC_MOVED_PERMANENTLY);
Please note that the setHeader and the setStatus method aren't methods of the ServletResponse class: they're included into the HttpServletResponse class.
The last thing to do is mapping the filter in the web module deployment descriptor:
$ cat WEB-INF/web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<filter>
<filter-name>RedirFilter</filter-name>
<filter-class>es.reacts.filters.RedirFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>RedirFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>
The application server bundled with Solaris 10 will complain with an not so intuitive "Unsupported minor.major 49.0 error" if you don't compile your application with a Java 1.4 compiler. Once this was done, you just have to deploy the web module into your server in the root (/) context path.
Setting up the network
The last part of the job was setting up the network. First of all, I removed the DNS A record identifying the www machine (which pointed to our hosting company web server) and substituted with a CNAME pointing to the machine of ours where I deployed the Java web module and then I configured our border router to map port 80 to the port where the Sun Java System Application Server is listening.
Manipulating URIs before redirecting
The filter described so far redirects a request to the root of an application to another URL. The basic problem with this example is that, if a client requests an URI beneath the root of an application, unless such URI is mapped to a valid resource into the application, the application server will return an HTTP 404 status code (not found). The filter semantics is such, indeed: they're executed before the request is handled by its target and, if it does not exist, they're not triggered at all.
To avoid such problems, if you want a catch-all redirection, or if you prefer to process the request before redirecting it, you can deploy a servlet and map it to the URIs you want to catch. And if you want to catch them all, mapping /* is all you need.
The final version of the web.xml of the web module I deployed is the following:
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<filter>
<filter-name>RedirFilter</filter-name>
<filter-class>es.reacts.filters.RedirFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>RedirFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<servlet>
<servlet-name>Default</servlet-name>
<servlet-class>es.reacts.servlets.Default</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Default</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>
