Glassfish is the reference implementation of Java EE 5, published as an open source project at
https://glassfish.dev.java.net. As such, it tracks the latest specifications from Java EE 5 - at the time of writing, the only server to attempt to fulfill the entire specification. It's also the basis for Sun's Application Server 9 Personal Edition.
Installing Glassfish is easy, although a little odd: Glassfish is distributed as an executable .jar file, and installation is done through java, but the installation requires a large heap. Thus, java -Xmx256m -jar [glassfish distribution jar] is used to install the server. After a license page, it then installs in ./glassfish, based on the current directory.
After this, ant is used to set up configuration for the specific host. There are two setup files, one for clustered mode and one for non-clustered mode. Initially, both will create the same kind of installation with few noticable differences, including a default domain (called "domain1"). Clustered mode allows the creation of multiple server instances on the same physical host, which isn't as useful as an actual cluster, but can still be useful for testing
purposes. (In addition, for this version of the server, there's an administration port issue; I had to change the admin port to 4849 from 4848 in the setup configuration files to get a clustered node agent to work.)
Clustering is still a work in progress, and the fact that it seems limited to a single host makes it rather limiting, and therefore, it won't factor in to this review any further other than to note that it looks promising for testing purposes at least; once a cluster is set up, it works well, propagating resource changes through the cluster as one would hope and expect.
There's a command provided for nearly all administration functions, including starting the packaged Derby installation. The normal process is to start the database (via asadmin start-database) and then the domain (asadmin start-domain domain1). The domain starts a local copy of Derby (called JavaDB by Sun) and IMQ (Sun's message queue) as well as the web console, which can then be accessed by any common browser - as long as that browser isn't Opera 9. (I used FireFox 1.5 with great success.)
The web console is very capable, providing log access (although the log access is a little coarse), resource management, application management, and monitoring - including call flow tracing, a very useful feature for seeing what happens inside of a deployed application. For most features, apart from cluster initialization and server startup and shutdown, the command line client isn't necessary.
The server itself is fairly stable, despite still having some niggling bugs. I've noticed that constant redeployments - a bugaboo of JavaEE development - have a tendency to lock up PermGen space, which necessitates a complete shutdown of the process (via kill on UNIX). There are also extant bugs related to filehandles being held in Toplink, the reference
implementation of JPA, which may be related to the PermGen issue.
That said, not deploying constantly seems to avoid the problem for the most part, so as long as your changes aren't miniscule and constant, you should be okay.
The server itself runs very well. Deployed applications run as you'd expect, actual runtime flaws (while present) are tolerable, especially considering that this is a product in development as opposed to a final version. (Users of Sun's AS9PE shouldn't be as tolerant of bugs as users of Glassfish V2.)
The user community is excellent for Glassfish. Reviews and features are highlighted regularly through the Aquarium, a blog centered around Glassfish, and the development community responds to bug reports quickly, as well as providing workarounds where possible.
As a server in development, though, there are still some problems: PermGen (as mentioned) can be problematic, and there are cases where filehandles are held (TopLink, as mentioned above), as well as some resources aren't freed when one would expect (to wit: a JMS exception that isn't accompanied by an explicit closure of the JMS session will leak that session, which is hardly what should be expected. This is a bug that has been accepted, and a fix is likely in the future.)
That said, it's important to note that this review applies only to Glassfish V2, and not V1; V1 is far more stable as a development and deployment platform, and some users are reporting that it's very good as a deployment server.
All told, Glassfish V2B15 is an excellent development platform, as long as you are aware of its occasional remaining bugs and are willing to shut down the server on occasion. The clustering support is useful currently for testing purposes only, and it's not bad as an actual
production deployment platform either, provided your application is well-behaved.
Joseph Ottinger is the editor-in-chief of TheServerSide.com, and has extensive experience in server-side technologies ranging from Perl to Cold Fusion to C/C++ and Java.
