Posted by writtmeyer
on February 20, 2008 at 1:14 PM PST
Glassfish v2 supports virtual servers pretty well. In this blog entry I will show how to set up virtual servers and how to map webapps to these using Glassfish's asadmin command line utility.
This is my first blog entry on java.net - so please be forbearing with me ;-)
For a while now I have been using Glassfish for all my private projects while developing. The webapp powering the German JSP-Tutorial runs fine using Glassfish while testing new features at home. Yet the live system of this site still runs on Tomcat. This is finally about to be changed soon!
I have set up a testing box at home on which I explore the paths to move my production machine over to Glassfish. The site and three others run on a linux box hosted by 1&1 . This box has one IP address only and my tomcat is configured using - and nested -elements to decide which webapps to serve for a given request.
The current configuration for the tutorial looks like this:
<Host name="www.jsptutorial.org" debug="0" appBase="webapps">
<Context path="" docBase="ROOT" debug="0" cookies="false" >
In order to run all my apps on one box with Glassfish I had to investigate Glassfish's virtual server features. The members of the Glassfish-team are blogging eagerly so I've found Jean Francois Arcand's blog and Jan Luehe's blog on this topic.
My requirements in a nutshell: I need four virtual servers for my four domains (jsptutorial.org , wolfram-rittmeyer.de , nosilverbullet.de and visualproxy.org ). Each of these domains must support an alias without the third-level domain "www". And on each of the four domains exactly one webapp shall be served. For any mistyped names or the IP address itself a default webapp shall be served to the client. And finally: All virtual servers shall listen on the same port.
So let's start adding virtual servers:
asadmin create-virtual-server --hosts www.nosilverbullet.de,nosilverbullet.de --httplisteners http-listener-1,http-listener-2 nosilverbullet
As a result you should receive the following message:
Command create-virtual-server executed successfully.
What I did here is adding the virtual server named "nosilverbullet" which is responsible for requests to the virtual hosts named www.nosilverbullet.de and nosilverbullet.de (--hosts argument). The --httplisteners argument indicates the listeners used for incoming requests. Both listeners are the default listeners created during the creation of a Glassfish domain. The listener named "http-listener-1" is used for non-secure requests and the one named "http-listener-2" is used for SSL 3.0- or TLS 1.0-secured requests.
The virtual server is up and running immediately afterwards (there is an argument to prevent this, should this not meet your expectations). But until now no webapp is associated with this virtual server. So it serves up files in its docroot path. If not specified otherwise this is the docroot directory of your current domain.
Of course I want my actual webapps to be served up. To get them running I could deploy them either as a war-file or as a directory. Since I control my server via scp and ssh only I prefer directory-based deployments. Whenever I want to change my app I simply have to upload a jar-file containing my Java class files and maybe some JSPs. A war-file would also contain all the libs specific to just one app and thus be much larger.
The asadmin command for directory-based deployment looks like this:
asadmin deploydir --name nosilverbullet --virtualservers nosilverbullet /path/to/dir
The result should be:
Command deploydir executed successfully.
You can verify your deployment, if you wish so:
asadmin get server.applications.web-module.nosilverbullet.*
Resulting into something like this:
server.applications.web-module.nosilverbullet.availability-enabled = false
server.applications.web-module.nosilverbullet.context-root = /
server.applications.web-module.nosilverbullet.directory-deployed = true
server.applications.web-module.nosilverbullet.enabled = true
server.applications.web-module.nosilverbullet.location = /path/to/dir
server.applications.web-module.nosilverbullet.name = nosilverbullet
server.applications.web-module.nosilverbullet.object-type = user
In case there is anything wrong, you might also want to use the following command:
asadmin get server.application-ref.nosilverbullet.*
It should produce an output like this:
server.application-ref.nosilverbullet.disable-timeout-in-minutes = 30
server.application-ref.nosilverbullet.enabled = true
server.application-ref.nosilverbullet.lb-enabled = false
server.application-ref.nosilverbullet.ref = nosilverbullet
server.application-ref.nosilverbullet.virtual-servers = nosilverbullet
This output shows - in this case in the last line - to which virtual server your app is mapped.
Finally my private website shall be served when either the IP address is used instead of a host name or when a host name is used that is not mapped in any virtual server (like "whatever.jsptutorial.org") but which nevertheless resolves to the same IP address.
To achieve this I changed the default virtual server for my listeners to that responsible for requests to wolfram-rittmeyer.de:
asadmin set server.http-service.http-listener.http-listener-1.default-virtual-server=wolfram-rittmeyer
asadmin set server.http-service.http-listener.http-listener-2.default-virtual-server=wolfram-rittmeyer
It is important to use both listeners to ensure that insecure as well as secure requests are served up by the default webapp of the default virtual server.
So this is all you need to configure virtual servers. But to actually move to Glassfish I still have to configure resources like my datasource connection pool and my mail provider for newsletter registration and delivery. But this is a topic for another post.