Skip to main content

Creating environment independent web applications on Glassfish

Posted by mriem on January 20, 2008 at 10:56 AM EST
Creating a WAR file that is completely identical between test and production is an interesting problem. In most cases the development team needs different settings for test and production. How can you do this effectively on Glassfish? See http://www.manorrock.com/documents/glassfish/independent.html.
Related Topics >>
Blog Links >>

Comments

by mriem - 2008-01-21 23:45

And have you considered getting the attention of the JavaEE expert group on this? I personally would prefer it to be part of the spec.

by whartung - 2008-01-21 12:21

I simply use a properties file.

http://wiki.glassfish.java.net/Wiki.jsp?page=FaqDomainProperty

Another technique is to make your application "self configuring" (specifically, give it enough reasonable defaults to be able to pop up a configuration page in the WEB GUI no matter what), and store configuration information using the Java preferences API. This lets you store things portably, without leveraging a DB.

by mriem - 2008-01-21 09:48

Correct binding it into the JNDI tree with this little library makes your WAR file 100% the same in every environment.

by whartung - 2008-01-21 23:00

I created an issue for this if anyone wants to comment on it. https://glassfish.dev.java.net/issues/show_bug.cgi?id=4024

by ljnelson - 2008-01-21 07:35

I see now what you are saying--you have a library that can bind things into the JNDI tree, so you are advocating that applications look up values from JNDI. Is that more or less correct?

by whartung - 2008-01-21 22:41

I don't know if GF has its own PreferencesFactory or not. (Though I do think that's a wonderful idea -- something that can handle both local and clusterable properties. In fact, I'm going to make a GF RFE when we're done here.)

The Pref API is a standard JRE thing, and I don't know if the JEE spec says anything about it. I bet they probably don't mention it. Save for the default not potentially behaving well in a cluster (specifically different instances within a cluster could have potentially different values), I don't think the JEE says anything about the Pref API. There's little reason it should, being that it hides the underlying mechanisms, and could easily be implemented directly by the container.

But the benefit of the Pref API is that it IS a JRE spec. In theory, any compatible JVM should have a Pref API implementation.

If you look at the Servlet spec, there is no GUARANTEED place to persist data. All that is guaranteed by the spec is a place to write TEMPORARY data.

On the other hand, the Pref API, again in theory, IS a guaranteed (via the JRE spec) place to persist data -- at least small amounts of data.

The lack of a place within the Servlet spec I found frustrating because there is no portable mechanism to ship a configurable WAR. A WAR that can bootstrap itself, present a UI to ask for Interesting information, and then run with that data. The only way to configure a WAR is to do it is through container mechanisms (like Connection Pools). But even if you used a JNDI extension as proposed here, even GF doesn't have a decent GUI mechanism to expose it, you have to hack the domain.xml -- not user friendly at all.

But with the Pref API and the availability of common, persistant storage, you can easily set up decent defaults that allow to at least be able to launch a configuration page that can be populated with site specific information.

Then your instructions to a user are, basically, "install Tomcat/GF. Configure Connection Pool. Go to http://localhost:8080/myapp/config". Voila!

Some folks make assumptions about the system, like writing info in to their home directory. Pref API is no different (though it uses the home dir on Unix, and Registry on Windows). For 99% of folks, this works fine, and while not per spec portable, it is in practice portable.

But the Pref API is per spec portable.

I do appreciate tho that the Pref API is an underused aspect of the JRE, and not well known.

by mriem - 2008-01-21 19:58

An interesting idea indeed. How well does this play with the JavaEE specification though?

by mriem - 2008-01-20 10:22

And how are you going to vary your value between test and production? Since that entry is included in your WAR file it effectively made your WAR file environment dependent. This article explains how to externalize it.

by ljnelson - 2008-01-20 10:18

I may very well be missing something here, but couldn't you do this with J2EE environment entries? Best, Laird

by ljnelson - 2008-01-21 19:34

@whartung: Hey, that's a neat idea; so does Glassfish ship with its own PreferencesFactory implementation? Or are you advocating simply storing property information using the default implementation (e.g. the registry on Windows)?