Full GlassFish adoption questionnaire responses from Florent Garin of DocDoku.

Date : January 2007

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

From a technical perspective, we started developing DocDoku as a plain Java SE application. The client front-end was implemented using the Java Swing API and the back-end system was made of basic RMI services. Progressively, as we were adding features, we were seeing ourselves implementing technical services that you get for free in a modern application server. So, we decided to migrate our software from a custom based architecture to a state-of-the-art Java Enterprise Edition application. When we started looking for a Java EE, we set the criteria as follows :

• It had to be open source
• It had to be Java EE 5.0 compatible

While this narrows the choice, we still had two options: JBoss and GlassFish. Finally, after a week of strong debate and prototyping, we selected GlassFish. Even if frameworks like Seam or Spring integrate great ideas, to preserve our investment, our strategy is to keep using the Standard as possible (Java EE 5.0 in our case). We’re convinced that, sooner or later, every valuable feature exclusively found in other alternative frameworks will fall back into the Standard.

How did you go about technically refactoring your code to use the Java EE 5 APIs? 

On the server side, switching from plain RMI services to EJB3 session beans didn’t seem to be a heavy task. The new annotation+POJO paradigm saved us from the burden of creating EJBs as in the previous version of the spec. However, the migration process involved some redesign decision. Specifically, one of our old RMI services was acting as a bootstrap, performing authorization and returning other service references when needed. The initialization of these services was done with nonserializable parameters. Such a pattern is inapplicable to the EJB world, since a remote business interface cannot define an init method that accepts non-serializable parameters. Moreover even if the same EJB object can be exposed through either a remote or a local interface, you cannot use alternatively both interfaces on the same object instance.

The side effect of replacing RMI remote objects by EJB session objects was also changing the underlying protocol from JRMP to IIOP. Unfortunately we encountered a strange bug in the J2SE IIOP implementation which had to do with failing IIOP-serialized enums comparisons. In my opinion, it's important to fix this bug given the Java Language Specification states that "there is only one instance of each enum constant". Anyway, the workaround is simple: compare the names instead. In the end, we were very satisfied as our code was drastically reduced (using annotations) and all the technical glue code were thrown away. The whole application could now benefit from the scalability of the J2EE platform.

On the client side, we didn't change our deployment mechanism. We're still using a standalone Java Web Start client. For the moment, we don't consider switching to the Application Client Container (ACC). However the idea of a client container is awesome, we're just waiting for more benefits to come with future evolutions than simply the dependencies injection. For the deployment part, the biggest problem we met was the need to carry out more than 15Mb of libraries (appserv-rt.jar and javaee.jar) on the client. It's very frustrating to have to deploy such libs when you know there are already tons of "corba" classes in the Java SE API. Hopefully,
after passing all the libraries to the pack200 compressor, the total size of the jars was reduced to 5Mb, which is acceptable in our case.

How and when did you first find out about GlassFish? 

I first heard about GlassFish on the java.net web site, maybe at the end of 2005.

What specific version of GlassFish are you using? 

V1 Milestone 7.

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

All our development workstations run on Ubuntu linux. The production servers are driven by a custom linux based on RedHat 7.2. Although it gives us full satisfaction, as the number of users increase, we will need a more powerful OS with features like ZFS or DTrace. Debian or Ubuntu with their large adoption could be good candidates. Solaris 10 is also an interesting alternative that could offer the advantage of one supplier (Sun) for the hardware, the OS and the application server.

What specific features or modules of GlassFish are you using?

Mainly the EJB Container (stateless, stateful and entity beans), the JDBC connection pooling, and the IIOP support for Rich Clients. For the web part we use Servlet and JSP. In the long term, we expect to develop a small web client with JSF that would expose the main features. 

What do you like most about GlassFish?

We want to have a productive platform and don’t want to waste time maintaining thousand of xml files. In that sense, the GlassFish web administration console perfectly fits our needs. Setting up the server environment through the web console is a real pleasure. Installing the mySQL jdbc driver, configuring the authentication realm (we used this JAAS module), the database connection pool, the mail session and so one can be done by a kid. Every imaginable parameter, from classic application entries (connection pool...) to complex management rules, can be set. For example, we also tuned the IIOP listeners to increase the Max Message Fragment Size parameter. GlassFish has also high end profiling and monitoring features. Really, the GlassFish web console is very impressive.

The integration with NetBeans is also very valuable. It doesn't take more than 10 minutes to write, deploy and run a "Hello world" Java EE application on GlassFish from a fresh default NetBeans installation. However, to be honest, I believe that as soon as the other Java EE servers pass the Java EE 5.0 certification the NetBeans open architecture will make it easy to reach the same level of integration.

What would you most like to see improved in GlassFish?

Smaller libs on client side to communicate with GlassFish and better documentation to support "legacy" features such as IIOP HTTP tunneling.

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

We base our development on the standard Java EE 5.0 framework so apart from TopLink Essentials which is included in GlassFish and accessed transparently through JPA we don't use other commercial or open source frameworks. However, on the client side we have dependencies on some third-party libraries like synthetica for the look and feel (commercial license), l2fprod-common which provides additional Swing components and JDIC for desktop integration.

Have you bought support for GlassFish?

At this point, the community support was sufficient. Having said this, it might be interesting for us to do so in the near future and would certainly save the team precious time searching the web as we did recently.

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

Yes, mySQL 5.0.

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

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

Three months have passed since we deployed GlassFish in production for our hosted service, the server always behaves perfectly and we never had to restart it!

How would your describe your participation in the GlassFish project?

For now, we didn't participate much. We were too busy bringing our product to market. However, we plan to do so. We're offering our application as a hosted service. The performance and the stability of the whole system is a key factor. It's our own interest to participate and thus benefit from the open source approach.

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