The guys at ZeroTurnaround (makers of JRebel) have been running a survey on redeploy and restart turnaround time in Java App Servers that has >1100 responses so far. The survey's 3 questions ask about AppServer usage and redeploy and restart time. Although doing a good survey is tricky - for example, in this case the sample is self-selected (but not as bad as with the Reader's Choice), the impact of (Re)Deployment tooling/configurations is unknown and the time is estimated, not measured - I think this one is useful in calling attention to the importance of the full develop/deploy/debug cycle. GFv2 did very well and v3 is even faster!

Jevgeni's analysis has some reasonable comments although some others seem unwarranted by the data. The most popular containers were Tomcat (29%), JBoss (25%), WLS (13%), WAS (12%) and GF (10%) (OC4J is 4%), with the caveat about self-selected samples. As a reminder of the importance of methodology, I'll point out that only 1 respondent listed Geronimo; readers may compare to that EDC Survey from Last Year.

Also note the impact of twitter and reddit in the comment thread - there are 117 comments as of this post... almost all of them very short 'heads-up' with no added value - sigh...

We just pushed out four new GlassFish Adoption Stories. Three of the stories are from telcos (from the US, the Netherlands and France), the remaining one is a health care company from Canada:

• SFR - Developer APIs, GlassFish-powered - Telco in France.
• T-Mobile, High Availability and GlassFish - Telco in the USA.
• Medavie Blue Cross - Standards Eliminating Vendor Lock-In - Health Care in Canada.
• Pretium Telecom - GlassFish ESB in Telco - Telco in The Netherlands.

We've previously covered N1 SPS (Service Provisioning System). This new article goes into much greater details about how such a solution and specifically its application server plug-in can help in your larger-scale multi-tier deployment scenarios. The article specifically goes into what a master server and a remote agent are, how a local distributor can help optimize network and firewall communications, how the concept of a component maps to a GlassFish domain or cluster, and how a plan is really a set of instructions requiring a set of variables to be executed. Running a plan can be done as "preflight only" or for real "deployment".

You'll learn how N1 SPS can provision existing installations of GlassFish v2 or carry out entire installations and deployments of SJS Application Server 9.1. This product is really meant for the provisioning of multi-tier deployments. For instance, it lets you install the load-balancing plug-in in the web server tier or manage HADB installation and node management.

Daniel has a very Complete Post on clustering of Web Apps on GlassFish. He covers installing GF, setting up the domains, setting up the cluster and deploying the app. To really take advantage of clustering you need to put a load balancer in front, something like Sun Web Server LB or Apache with mod_jk. Dan promises more blogs. It is nice to see more examples and documentation on clustering and failover on GFv2. The beta2 release (due by JavaOne) will be very functional and we will have tested on "small" clusters (4-8); expect more testing and in larger clusters before the final release. All performance numbers so far are very nice.

Edit, compile, deploy. It's a familiar cycle for anyone involved with the development of Java EE applications. But until recently, the "deploy" portion of the cycle lacked standardization. JSR 88 changes that (by providing standard APIs to deploy an assembled application onto an application server). And, as usual, GlassFish is one of the first containers to support this new standard. Japod has put together a detailed example showing how to use JSR 88 for web application deployment in GlassFish. Or for more on the subject, see the GlassFish Deployment Project.

Harpreet reports on the ongoing Java EE 5 SDK Contest. The SDK includes SJS AS 9.0 PE UR1 (Sun's distribution of the final bits of GlassFish V1 UR1), and the contest is to encourage you to fill in a survey to understand better your needs, specially around deployments. As you enter the contest, please also consider adding your site - if applicable - to our GlassFish Adoption Wiki page.

Profile support is a key mechanism to make GlassFish V2 usable to simple developers and complex deployments. Kedar will be presenting the current proposal today, Wednesday, at 9am Pacific (GMT-7) time. I meant to post this yesterday but I scheduled it for the wrong day, my apologies for the short notice! Check the One Pager, and participate in the concall. For more information and future meetings, check the UE Wiki page.

Now, here is a question for the community. I would like to see more Non-Sun participation in these discussions, and I'd welcome suggestions on how to improve that. The current approach used by the GlassFish team relies on concalls to quickly cover the material initially, but a concall requires synchronicity and makes it hard for a casual or latecomer to participate. Groups like Apache rely on mailing lists, but these can drag over long periods of time - and email conversations do not work very well over +11 TZs.

In the brave new world of Wikis, forums, flashd demos, etc... do you have suggestions on how to increase participation without substantially slowing down development? Let us know your ideas so we can start trying them out.

If you are using GlassFish on Windows and are deploying via archives (like EAR, a WAR, an EJB JAR, or an app client JAR) you may have encountered a variation of GlassFish Issue 539 where a problem during deployment leads to a locked JAR that requires a server restart. The good news is that Tim and Hong have checked in changes to address this problem: when possible the problem no longer occurs and, when it does, there is a nice error message that leads to a prompt resolution.

Expect the fix in the next promotion of GlassFish V2. Check Tim's Blog for a detailed description of the problem and the solution.

The CORBA implementation was recently Released as part of Project GlassFish. In his most recently blog entry, Ken describes how Stubs and Skeletons are Dynamically Generated in the current implementation to substantially reduce deployment time (full details are here). Although this CORBA implementation is very solid, there are changes planned in the near future and Ken also mentions some of them (also check the GlassFish-Corba home page). As with all components in Project GlassFish, we are actively interested in participation; if you are interested contact the team or Ken directly.

The photo: the Earth from Apollo 17, a fairly small Orb, as galactic objects go, but a bit bigger than other famous orbs.