By dochez on Nov 06, 2008
Today we are releasing GlassFish V3 prelude, as the architect for the product, I feel compelled giving you my view of what this release mean for us and for you. After an aggravated loss of hair, endless evenings working on various bits and pieces and bringing together a great team of talents, I am proud of what we have achieved so far :
Major rework of the GlassFish code base, refactoring, modularizing, removing code was not a trivial task and we learned a lot about software practices when dealing with a module environment.
Extensibility is the huge value of prelude and V3 in general. Modularity is good but you might ask yourself, why is it good for me ? In a nutshell, extensibility is the answer. With modular application server, you can shrink it or extend from the smallest distribution (Rails Gem, about 3Mb) to the most sophisticated distributions like Prelude with metro stack (about 35Mb)
Developer features. What do developers want ? something fast, that does not get in they "way" and be productive. Prelude starts in less than 2 seconds on my screaming fast PC. It has new features that can change your life as a Java developers (more below), you really should try it out if you want fast iterative development cycles.
First Java EE 6 features available through the update center and more to come. (In fact, if you are brave and take our nightly builds, you get even get the servlet 3.0 features already).
It's always hard to blog on general features about something as important as an application server but let me give a stab at the things I believe you should know.
As you probably know by now, GlassFish V3 prelude is based on an industry standard OSGi R4 implementation called Felix, Sahoo has been championing this integration, and Richard Hall (dev@felix) who joined Sun in the meantime are the references for any OSGi related information. It also run on Equinox if you rather use that environment.
Modularity was a necessity for us because it's been increasingly difficult to reconcile the growth of the Java EE platform, the choice of third party technologies that people want to use in their applications with the demands for a fast responsive application server. Modularity was the only possible solution, that allowed us the split appart the implementations in different parts and then through some intelligence with starting the different capabilities installed we have managed to keep GlassFish V3 startup time linear independently of how many features are actually installed.
Pay as you go ! Modularity is great but what is very important is to leverage modules and service based architecture that will allow for lazy initialization of features as they are requested. In fact, I believe that if you do Modules even based on OSGi but you don't rework your architecture to allow for lazy loading then modularization is an overhead more than an advantage. I already know of a few examples of application servers like that ;-)
So in V3, startup is 2 seconds, deploy a web application, take another 2 seconds hit, deploy yet another web application, 50ms. Get the picture ? Startup only really read the configuration (domain.xml) and starts Grizzly. The first web application triggers the web container start up, takes another 2 seconds. Yet if you deploy yet another web application or redeploy the fist one, this time, it's only 50 ms since everything has been started.
Modularity was also a good way of providing new features, especially around extensibility. I have spent a lot of effort into designing crucial extensibility parts of the application server.
Probably the most important design center of V3 is to become "The" container for server side Java. So if you have some piece of application that runs on a server and gets invoked remotely (e.g. http, corba, etc...), you can run it on GlassFish. In fact, it's even more than Java, it really is about anything server side on the JVM. That's why today we support technologies like Rails (with the JRuby interpreter) or Grails in V3.
As you may know, GlassFish is configured through the domain.xml file. Up to V3, this file had a structure we were defining and could not be extended. Starting in V3, anyone can provide facilities that will be discovered and used to load and store third party configuration artifacts. Why is this important ? Say you have a special library or container that is available on GlassFish, you would want to provide a nice unified configuration of GlassFish to the user and to do that, you should put it in domain.xml. Also when clustering features will be available, the infrastructure will take care of transfering these artifacts to remove server, etc.
3. Admin Commands
As you extend the application server, you want to be able to add new administrative commands to configure your extensions. This is both necessary for remote configuration, but also for again giving users a feeling of a unified product.
4. Admin GUI
Last piece is to be able to extend the console, which is our GUI front end to modify the application server configuration. A plugin architecture has been developped to help external users to extend the console, this is the last cornerstone to again providing a nice unified view of the product's configuration.
Kohsuke has done some work to make GlassFish V3 prelude embeddable. Check it out there, it allows for running V3 prelude in any native or java process, pretty cool...
In V3, we have added a few features which will radically change your productivity in server side Java development. First of all, keeping sessions on redeploy, and compile on save.
When developing an application that heavily uses HTTP sessions to keep user's states, development can be very tedious. You test the application, find a problem, edit the code, compile, build, deploy and then you have to recreate your session when the problem occured (for instance recreate the shopping cart). In V3, you can now preserve sessions during redeployment so that you can basically reload the page in the browser to test the new code you have added.
2. Compile on Save
Latest Java IDE have had this features of underlying invalid code or provide a lot of metadata and most of that is done by compiling the code behind the scenes. Now it was only a step to be able to hook up some events when the recompilations of edited code was successful (on a save of course) and force redeployement. We have added this intelligence to both the Netbeans and Eclipse plugins so we can now redeploy the application when you just "save" the java source file.
So now combine the two features and from the long list of actions you had to do to test new code you are down to only save the source file. You overall iterative development cycle is test the application, find a problem, edit the code, test the change. This is what scripting languages have provided for years, yet this is Java so you can get the best of both worlds.
These features are available with Netbeans and Eclipse, check out this on how to use those plugins in your favorite IDE. Check it out there, he should be giving out some nice screen shots on how to do that.
I am personally very excited by these two features and I truelly believe that if you only want to spend 15 minutes trying GlassFish, this is what you should try, because that's my best shot at convincing you of using it a lot longer...
Have fun, download the prelude from there and give us feedback.