vendredi sept. 11, 2009

Which GlassFish v3 download bundle is right for me?

(updated October 2010)

You may have read the (recently updated) page comparing GlassFish v2 and v3 and decided to go with v3. The next question you might ask yourself is which bundle should I download? Why is the zip archive bigger than it "installer" equivalent? Here is some data to help you decide.

Zip or installer?
The zip installer is new in v3 and the same for all platforms. As the name implies, unzipping is all you need to do. A default domain1 is already available. If you use the graphical installer (now open source, which makes the difference between community and Sun-branded version even smaller, but see later paragraph on that), you'll be able to change port, JDK, install, etc. This "installer" bundle comes in two flavors - windows and Unix-like (an .sh script which works on Linux, Solaris, and the Mac). The installer also let's you do silent installs with a statefile which can be produced without doing any actual install.

The IPS/pkg/updatetool feature of GlassFish (which I've been talking about it a fair bit on this blog) is quite unique for an appserver, and as you may already know this is written in python and thus ships with a "native" minimal python runtime. As a consequence, to avoid having lots of different artifacts (one per platform), the ZIP or installer bundles do not contain this by default. The zip version will require the user to install pkg and updatetool the first time the command is invoked (network access is required). The installer will offer to do that as part of laying out the bits.

You may also note that the ZIP bundle is actually bigger (25% to 30%) than the installer archive. This is because pack200 (un-)compression (much more efficient on JAR files than PKZIP) kicks in as part of the installer process.

Web or Full profile?
That's an easy one since no matter which one you chose, you can install or remove packages to get the feature-set offered by the other profile. The download page (for instance on has the details of what's included in which profile. With only 30 MB, the smallest download is a Web profile installer. The largest is the zip archive of the full profile at 70MB.

GlassFish Open Source Edition or Oracle GlassFish Server?
Technically speaking, the differences are minimal. The license and the branding (a new feature in v3, the software is now fully and easily brand-able) are the two notable differences (another minor one is the different IPS repositories). Feature-wise, the two distributions are the same. Of course, the big difference lies in the fact that only the Oracle-branded version (Oracle GlassFish Server) is supported and usable in production only with a commercial license (otherwise the use is under the OTN evaluation license). It is also quite easy to upgrade an Open Source Edition installation into Oracle GlassFish Server.

vendredi oct. 03, 2008

Bundling GlassFish v3 Prelude - XWiki and the GlassFish Embedded (Part 2)

Update: things have changed quite bit since I wrote this for v3 Prelude (now v3 Final is the way to go).
Please check this link for up-to-date info on GlassFish Embedded.

In Part I, I covered a first technique to bundle the XWiki application with GlassFish v3 Prelude. The distribution and packaging discussed included a "traditional" auto-deployment of a web application (WAR) in a lightweight application server (GlassFish v3 Prelude).

GlassFish Embedded API

XWiki is a non-trivial application and I felt it would be a great test for the GlassFish Embedded API. This enables GlassFish to run in-process as explained in the rest of this entry. While the embedded API can be very useful for testing (it can now already be used with Maven and Grails for instance), the goal here is to produce a self-container Java SE application which contains GlassFish Embedded, the XWiki WAR archive and some glue code to start glassfish and deploy the application

Putting the pieces together

GlassFish Embedded does not use OSGi but rather a more traditional class-loader hierarchy so I had to work around a "classical" JAR precedence issue:
• removed the log4j jar from the XWiki application and make it available as a library (appropriate Class-Path: entry in the manifest of the overall JAR).
• used <class-loader delegate="false"/> in sun-web.xml to avoid further library conflicts (documented here)

Using the GlassFish Embedded API is pretty straightforward :

import org.glassfish.embed.App;
import org.glassfish.embed.AppServer;

public class XWikiOnGlassFish {
    public static void main(String[] args) throws IOException {

        AppServer glassfish = new AppServer(8080);
        App app = glassfish.deploy( new File("/path/to/xwiki-enterprise-web-1.5.2.war") );


The application weights 20 MB for the full GFv3 Prelude embedded (see other distributions here) + 4Ko "glue" application + 40MB XWiki.

The startup time is as follows:

with an additional 12 seconds to load the XWiki web app. The memory consumed (used heap as reported by VisualVM) is 15 MB right after the welcome page is displayed and 35 MB after exercising the application a bit.

I'll leave the packaging of this Java SE application (see what the OpenSSO guys did) using Java Web Start as an exercice to the reader.

More coverage of the GlassFish Embedded API (including the ScatteredWar API, and the Maven integration) can be found here. Note that a few API changes happened since that post.

jeudi mars 27, 2008

Sun AppServer (GlassFish) / MySQL bundle now available

It's only been a few weeks since Sun announced the close of the MySQL AB acquisition (which really didn't take long) and we now have a bundle of Sun Application Server 9.1 (GlassFish v2) together with MySQL.

The full distro is less than 150 MB (double that once installed on disk). It includes the open source GlassFish v2ur1 app server (Sun App Server 9.1ur1), MySQL Community Server 5.0 and of course the MySQL JDBC driver (version 5.1.16). You can get the bits off of HERE. They are available for Solaris, Linux, Windows, and Mac. Check out the "Installing Application Server 9.1 Update 1 with MySQL Community Server" documentation, the Release Notes, and Sathyan's entry and sample application.

The database default "SMALL" install option corresponds to a system using 64 MB memory or less (typically a developer platform).

Once installed (interactive and silent installs available), the application server can be started using this simple command (or simply during the install process) :
% INSTALL_HOME/bin/asadmin start-domain
The application server documentation is here.

... it takes the following few set of commands (documented here) to get MySQL going :
% sh INSTALL_HOME/mysql/scripts/mysql_install_db (to initialize the grant tables)
% INSTALL_HOME/mysql/bin/mysqladmin -u root password 'new-password'
% INSTALL_HOME/mysql/bin/safe_mysqld [--defaults-file=install-dir/mysql/mysql.ini --user=root] &
The mysql.ini config. file is located in INSTALL_HOME/mysql.
To find more information on working with MySQL: Getting Started, Full Documentation.

Creating a connection pool to the MySQL DB using the web console is pretty simple (command-line equivalent is % asadmin create-jdbc-connection-pool ...):

No separate JDBC driver to install :

Testing the connection is always worthwhile (command-line equivalent is % asadmin ping-connection-pool ...) :

Support for Sun Application Server/GlassFish starts at $4500 for 4 sockets while unlimited supports calls for MySQL Enterprise starts at $1999 per server. Access to patches (sustaining branch) is included in both support plans.

I have very regular discussions with GlassFish clients, system integrators, ISVs, and OEMs and the most common question (a fairly valid one too) I've been getting is this - "Great product experience and great roadmap, but how serious are you about this Open Source model?". Needless to say that I haven't heard the question since the MySQL acquisition.

mardi nov. 06, 2007

GlassFish/SJS AS in production - which bundle, which profile, ...?

You may have heard it before, GlassFish v2 is a single bundle (no more "Editions"). So why bother writing a post about this? Well, the reality is a little more complex.

First you need to choose between the GlassFish v2 bits (simple ANT-based installer) from and the SJS Application Server 9.1 (more polished installer). Both end up installing the same JARs (see this FAQ entry for more on the differences between the two approaches). As explained in this previous post, you should be using SJS Application Server 9.1 bits for patches to be applicable.

Profiles in GlassFish v2 are "developer", "cluster", and "enterprise". The difference between the first two is pretty much self explanatory. The "enterprise" profile is mainly related to the use of HADB (highly available and distributed database) and a different keystore. Note that HADB is not open source (more on its relevance later). Here are the other main differences:

You can have any profile in production, including "developer". In that case, you should probably tune GlassFish (default tuning is done for developers) and certainly remove the fast startup:

The GlassFish bits provide support for the "developer" and "cluster" profiles. Chose between the two at install-time (setup.xml or setup-cluster.xml) or upgrade using the "Add clustering" web admin action to a "developer" instance. There is no "entreprise" support in GlassFish bits.

The SJS Application Server 9.1 bundles provide the choice between Application Server 9.1 and Application Server 9.1 with HADB. The first one is roughly the equivalent of the glassfish bits from (with no setup.xml, use asadmin create-domain instead). The second one contains HADB.

The difference between "cluster" and "enterprise" really boils down to the technology used for replicating data to provide high availability. The first one uses in-memory replication based on the Shoal framework while the second one uses HADB. This is a trade-off between degradation and availability:
• "cluster" is providing availability (not sure how many 9's, but that's clearly less than 5) with a very reasonable performance degradation (depending on your session size and application obviously).
• "enterprise" is 99.999% available, but performance can be less than half what it is without any data replication.

The other important thing to note here is that the "cluster" profile is very easy to setup while "enterprise" does require installing and administering HADB nodes.

Once you have either "cluster" or "enterprise" profiles in place, you simply need to :
•  Deploy your application with availability-enabled=true
•  Make sure the application is deployed with the <distributable/> element in web.xml

One question I often get is "What if I want clustering and load-balancing, but no data replication"? This can be achieved by using the "cluster" profile and deploying without the above two steps. In that case, load-balancing can still happen (using GlassFish's software load-balancer) or any external one with a sticky behavior - sessions live on only one instance and users are always redirected to this instance. If the instance fails, all associated sessions are lost. A great deal of applications can live with that.

If you'd like to hear more about clustering with GlassFish, the freshly released episode #003 of the GlassFish Podcast is an interview with Shreedhar Ganapathy.


This blog has moved

Alexis Moussine-Pouchkine's Weblog

GlassFish - Stay Connected


« avril 2014

No bookmarks in folder


No bookmarks in folder