I am happy to announce much awaited release of GlassFish gem ver 0.9.3. This release has many critical improvements and bug fixes.

Here are the highlight of new features:

Daemon mode

GlassFish gem is started by JRuby, which starts a JVM in which GlassFish runs. In daemon mode, GlassFish forks itself with the optimal JVM settings as a daemon process and writes out the process id in to a file. The default filename is tmp/pids/glassfish-<PID>.pid. To stop GlassFish gem server, you would send it SIGINT. This process id file is automatically deleted when server is stopped using SIGINT. This will enable kill and bounce of GlassFish gem server.

You can override the name and location of the PID file using -P or --pid option. At any time if you want to clean up zombie  PID files, simply run the following rake task inside your app directory:

[~/dev/depot]$ jruby rake tmp:pids:clear

The daemon mode is made possible by using Akuma, which is another very useful library from Kohsuke. I am very interested in experimenting with the Network Server feature and see how it can help us create GlassFish gem cluster.



During daemonization, during fork, daemon logs are written in log/glassfish-daemon.log file. Here, the time stamp, name of the PID file and other informations are recorded. This file is appended with the each new daemon instance. Rest of the server log goes in to usual logging file.

Daemon mode will enable Capistrano style deployment for GlassFish gem. Jacob is going to start working on the Capistrano recipe for GlassFish gem as well.

GlassFish rake task

A new rake task, gfrake is introduced in this release. It basically would let you create a template configuration file (see below about what it is) and clean up glassfish generated temporary files.

Configuration

At times, specially in production you would like to define the configuration information in a static file instead of wrapping CLI options in another script. Now you can do so by creating a glassfish.yml file in the config directory. To create it run gfrake config inside your application directory. By default, GlassFish gem looks for glassfish.yml inside the config directory. You can override it by passing your own using --config option.

glassfish.yml contain not only CLI but other options as well. For example, you can define the JVM options with which GlassFish should start in daemon mode. This would be useful to tune the JVM to get  optimal performance for your given hardware resources.

Please note that this is the first version of configuration file and in latter releases will include more options. Although we will be very careful about not breaking backward compatibility but if it happens, such decisions will be taken judiciously and communicated.

sudo not needed any more

This is really not a feature rather a bug fix. GlassFish gem is based on the GlassFish v3 kernel. A fundamental aspect of GlassFish v3 server is that it runs an instance to serve a domain and the domain by default is located inside the GlassFish gem install location. This is a real problem for those who install GlassFish gem in a root privilege location. When trying to run glassfish with user privilege would fail as glassfish would detect that it can not write in the root privilege location. This has been reported by many users.

The real fix is in GlassFish v3 where such error reporting are deffered and since there is no write in case of gem, such deffered checks will not cause failures for gem.

In the mean time, GlassFish gem has a temporary solution, on startup it creates a temporary domain inside tmp/.glasfish of your application directory.

Improved logging

Unlike previous versions of gem logging is not displayed on the console. On startup, GlassFish gem displays basic information and the logging goes to log/development.log or whatever your environment is. For example, if you are running the app in production, logs will go to log/production.log.

You can override where logging should go using -l or --log option.

[~/dev/depot]$ glassfish -l mylog.log

You can easily control the log level using --log-level option. The various log levels are:

Improved error reporting

There have been many improvements in the error detection, reporting. For example, instead of reporting port is busy after server starts, the check will happen early on, various validation improvements etc. This is a continuing work and with every release we will improve on anything that can make it easier to diagnose and help fix the problems.

Support for Sinatra and framework auto-detection

Beside Rails and Merb Sinatra is supported as well. GlassFish supports any Rack based framework. To run your framework of choice simply place the rackup script (.ru) inside your application directory or set JVM property -Djruby.applicationType=/path/to/myframework.ru and GlassFish will plugin your script automatially.

Save the code below in a .rb file and simply run glassfish in that directory and access your RESTful service at http://localhost:3000/.

require 'rubygems'
require 'sinatra'
get '/' do
"Hello world"
end

Server busy handling

In prior releases, when GlassFish gem is busy loading the application, a new request will give 404 HTTP error. This causes problems when you front-end Glassfish gem with some LoadBalancer, as it would treat 404 as client error and would not know what to do with it. This is fixed. Now, when GlassFish gem is busy loading application and a new request arrives, it will give a 503 (Server Unavailable) and a 'Loading application..." page and the load balancer will know not to route to that server while the 503 is in effect.

Check out README and start using GlassFish gem and send your feedback to the forum and report any issues at the issue tracker.