vendredi juil. 10, 2009

Top reasons why GlassFish v3 is a lightweight server

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

I have been involved in helping a couple of consultants put together a presentation on the future of app servers and one thing that struck me was that in the resulting slides, they equated lightweight appserver with the use of the Spring framework. Using Spring in WebSphere doesn't make any lighter. I don't think that deploying an archive with 90% being runtime qualifies as lightweight (hence the SpringSource tc and dm server offerings), but I also think that painting every application server as being monolithic and heavyweight is a gross caricature, so here are my top reasons why GlassFish \*is\* a lightweight application server.

#1 • Download size
For some people download size matters. For them and for everybody else, GlassFish v3 downloads start at 30MB for the web profile (get it here). The updatetool will then help you scale up or down from there. Of course you can also start with the "a la carte" approach and go even lighter (20MB for a functional RESTful+EJB31 server). Some others are fighting hard to fit on a single DVD or CD.

#2 • Pay for what you use
With the extensible architecture of GlassFish v3, services and containers and brought online only when artifacts using them are deployed to the runtime. Deploy your first WAR and the web container will take a couple of seconds to start. Deploy your second webapp in a fraction of a second. Remove the last webapp and the web container will not be restarted on subsequent server restarts. Some people call that on-demand services.

#3 • Fast (re)deployment
Beyond incremental compilation (which most IDE's offer nowadays) and deploy-on-change (simply save the source and reload the web page), the time to (re)deploy an application is key to a developer's productivity. The GlassFish team has spent time optimizing that process to offer sub-second redeploy time for simple applications. GlassFish v3 also offers the preservation of sessions across redeployments which is a pretty safe operation (new class-loader, new application) and costs less than 5 seconds to recreate a Spring context (for instance with the jpetstore demo on my laptop), and even less on traditional JavaEE webapps. This is all built into the product with no configuration or add-on required. Check out this recent (and short) screencast for an illustration.

#4 • Startup time
Even in the days of (fast) redeploy, startup time still matters to both developers and operations. GlassFish v3 starts in about 3 seconds with a warm felix cache. Starting the web container is about an extra 3 seconds. Deploying individual applications depends largely on their size and complexity but let's say that it starts at around 100ms and should not go beyond 30 seconds. Starting GlassFish v3 with Apache Roller already deployed (not exactly the lightest webapp there is out there) will cost you about 20 seconds.

#5 • Memory consumption
One might think the OSGi nature or the application server introduces an unwelcome memory overhead. For an application servers like GlassFish v3, that certainly isn't a problem as a base GlassFish v3 runtime is using less than 20MB (another "side effect" of the modular & extensible architecture) and a non-trivial application only 50MB of heap (as reported by visualvm). Not quite small enough to run on a feature phone, but that may well happen sooner than we all think, especially when using the Static mode (no OSGi) and the embedded api.

#6 • Spring \*and\* OSGi
No need to choose between standard JavaEE, Spring, and OSGi. You can have all of the above in a single integrated product. In fact you can even use the unmodified OSGi-fied Spring DM version of the framework, and make it available at the expense of a couple of clicks in the update tool. The HK2 layer in GlassFish v3 is abstracting OSGi away and manages to have GlassFish retain its lightweight feel while allowing for Java EE components to inject any OSGi-based declarative services at the expense of a standard @Resource annotation. I don't know if you think this lightweight but I certainly find this to be an elegant integration.

#7 • Open Source
GlassFish is open source, so you can make it whatever you want, even a heavyweight monster if you so decide! Certainly the barrier to entry for using GlassFish is very lightweight.

But the real question is - is GlassFish v3 lightweight for you(r application)?
Whatever the answer is, I'd love to hear your comments and experience!

mercredi oct. 03, 2007

SDPY - GlassFish vs. Tomcat (reloaded)

This was certainly already an interesting comparison two years ago and still is now:
•  GlassFish vs. Tomcat
•  Automatability: Tomcat vs Glassfish
•  Switched
•  GlassFish 2 vs. Tomcat 6
•  GlassFish and Tomcat Comparison

GlassFish still has ways to go, but it has a plan.

jeudi févr. 15, 2007

How to use Tomcat Context information in GlassFish

If you're using Tomcat and you are looking into moving to GlassFish (because of Java EE 5, admin tools, Grizzly performance, etc...), you might find this question I was asked twice recently about a specific feature migration.

If you were using Tomcat's Context feature and reading the initialization parameters say from servletContext.getInitParameter(), you need to provide the same information in a slightly different format in the standard web.xml deployment descriptor.


Note this can also be added to $GLASSFISH_HOME/domains/$DOMAIN_NAME/config/default-web.xml if you don't want to repeat this in all your web-apps. But be careful as it takes precedence over the web application web.xml.


This blog has moved

Alexis Moussine-Pouchkine's Weblog

GlassFish - Stay Connected


« septembre 2016

No bookmarks in folder


No bookmarks in folder