New features in GlassFish 0.9.3 gem
happy to announce much awaited release of href="http://glassfishgem.rubyforge.org/">GlassFish
gem ver 0.9.3. This release has
many critical improvements and bug fixes.
Here are the highlight of new features:
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 style="font-weight: bold;">tmp/pids/glassfish-
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 style="font-weight: bold;">-P
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 href="https://akuma.dev.java.net/">Akuma,
which is another very useful library from href="http://weblogs.java.net/blog/kohsuke/archive/2009/01/writing_a_unix.html">Kohsuke.
I am very interested in experimenting with the href="http://weblogs.java.net/blog/kohsuke/archive/2009/02/writing_a_multi.html">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
Daemon mode will enable Capistrano style deployment for GlassFish gem.
is going to start working on the
Capistrano recipe for GlassFish gem as well.
GlassFish rake task
A new rake task,
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.
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
file in the config directory. To create it run style="font-weight: bold;">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 style="font-weight: bold;">--config
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
optimal performance for your given hardware resources.
Please note that this is the first version of configuration file and in
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
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
You can override where logging should go using style="font-weight: bold;">-l
[~/dev/depot]$ glassfish -l mylog.log
You can easily control the log level using style="font-weight: bold;">--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
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
Beside Rails and Merb
is supported as well. GlassFish supports any Rack based framework. To
run your framework of choice simply place the rackup script ( style="font-weight: bold;">.ru)
inside your application directory or set JVM property style="font-weight: bold;">-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/.
get '/' do
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 href="http://glassfishgem.rubyforge.org/">README
and start using GlassFish gem and send your
feedback to the href="http://rubyforge.org/forum/?group_id=5450">forum
and report any issues at the href="http://rubyforge.org/tracker/?atid=21080&group_id=5450&func=browse">issue