Full GlassFish adoption questionaire responses from Adam Constabaris, Applications Analyst at ITS Knowledge Management, University of North Carolina at Chapel Hill.

Received June 25, 2007.

Can you tell us about the application, site, or service in which you have adopted GlassFish?

We run a document management system that underpins our campus' IT knowledgebase. The system provides for reviews, "freshness" checks, and publication controls. The documentation source is DocBook, so we also provide a few tools that aid with DocBook authoring. The content is delivered to the campus by a separate application (which uses Tomcat); the two applications communicate via the Atom Publishing Protocol (AtomPub).

How and when did you first find out about GlassFish?

It seems likely to me that it was through java.net.

Did you go through an evaluation process before selecting GlassFish? If so, can you tell us a little bit about the process and results?

A fundamental question for us in building this application was whether to use Tomcat and "soup it up" by using Spring to add services Tomcat doesn't provide itself, or whether to use a full Java EE container. We could have made it work with the servlet container approach, since our application isn't heavily "enterprisey" and we were initially reluctant to pay the complexity price of EJBs. After looking at the Java EE 5 specification, though, we saw a lot of ways we could simplify and standardize things, such as using JSF 1.2 and coding to the Java Persistence API rather than using Hiberrnate APIs directly. The ability to share out a JPA persistence unit across several web applications in the same EAR and having other services available such as JMS pushed us in the direction of a Java EE container. Since a lot of the functions (e.g. running XSLTs) can take quite a while and we don't want our users to experience long waits, there's quite a bit of asynchronous processing going on. At the time we made the decision, Glassfish was the only production quality Java EE compliant container that fit our budget, and so, well, here we are.

What specific version of GlassFish are you using?

Fully patched V1 (V1 UR1 P01).

On what operating system do you run GlassFish? Do you use the same OS for both development and production deployment?

We use Linux end-to-end, taking into account developer workstations, development servers, and production servers. They all run various flavors of Red Hat (Fedora, RHEL3 and 4); our production system is RHEL 3.

On what hardware platform do you run GlassFish? Do you use the same platform for both development and production deployment?

Our production server is relatively modest, it's a dual PIII Xeon whose speed is not measured in multiple gigahertz; our development servers are virtual machines that are supposedly roughly equivalent to a single CPU P4 3Ghz. Since the application doesn't see a lot of users at any one time, it performs acceptably on both platforms.

Have you purchased support for GlassFish? If not, have you thought about doing so?

We have not purchased support; it is possible that if our availability requirements became more stringent than they currently are, we would do so.

What specific features or modules of GlassFish are you using?

We endeavor to code to standards wherever it's reasonable to do so; this fortunately turned out to be just about everything! So we're not making use of any of Glassfish' particular features, as opposed to what the Java EE specification defines.

What do you like most about GlassFish?

Initial installation and configuration are relatively unintimidating; the web-based admin console seems to work pretty well for us too. And, while it's not a feature of the software as such, I've found Glassfish developers' blogs quite useful, along with the ability to poke around in the source code.

What would you most like to see improved in GlassFish?

Logging configuration. It's far more difficult to separate out the log entries generated by the application from those generated by the container than it ought to be; we had a significant amount of trouble just getting our application's logging output into the global log, which made testing and debugging a rocky process. The ability to plug in a different logging package might also prove useful.

Are you using any open source or commercial frameworks or tools in your application?

We use a lot of open source frameworks in our applications. We're using Spring and Acegi, Facelets, Tomahawk JSF components, Nux and XOM, Abdera (AtomPub implementation in incubation at Apache), AspectJ, SVNKit, the Sesame RDF Framework... it goes on. We're using Hibernate as our JPA provider.

Does your application use a database? If so, which one?

We're currently using Oracle 10g.

Are there any figures about the scale of your adoption which you would like to share?

Our reasons for choosing Java EE 5 and hence Glassfish were more about ease of development rather than any ability to handle high volume. While choosing Java EE 5 probably increased our development time a bit compared to that required by our other architectural options (in that we haven't used EJBs before), we hope to make up for that in terms of maintainability.

How has GlassFish performed since your application went live? Have you run into any production issues which you would attribute to GlassFish?

We haven't seen any performance related issues so far, but then again we're not pushing our application very hard =)

How would your describe your participation in the GlassFish project?

I've submitted one bug report, and jumped in on the developer IRC channel now and again. I blog about it now and again.

Is there anything else you think would be of interest in a story about your GlassFish adoption?

I can't really think of anything I didn't mention above.