{#asciidoc} = GlassFish Administration: The REST of the Story Part II - Deploying Apps Using Scala Jason Lee 2010-12-17

In a previous post (far too long ago :), I began showing off the RESTful administration API in GlassFish v3. In GlassFish Administration: The REST of the Story Part I, I showed the basics of the API, what to send, what you get back, etc. In this post, I want to show a practical use of the API, namely, deploying an application, and this time, for no particular reason other than I’m trying to learn the language, we’ll do it in Scala.

{#asciidoc} = The Value of the Stack Jason Lee 2010-12-14

This morning on twitter, I saw an announcement that Mollom has a new backend, one based on GlassFish. I have to be honest. I don’t know much of anything about Mollom beyond this, nor do I know anything about their previous backend other than it was Java-based. The blog post, though, immediately made me think of dynamic languages.

These days, it’s hot to be dynamic, whether it’s Ruby, Python, Groovy, or something else. There’s no denying that they have some very compelling features. One of the quotes in the blog post, though, really stood out to me:

As I’ve noted, their former architecture was Java-based, but the same idea applies to the typical deployment of projects based on dynamic languages. While readily admitting I’ve done precious little with dynalang projects in the enterprise, from what I’ve read and have heard people discuss, it seems the most common deployment scenario is, for example, Apache httpd with mod_foo installed. There might even be a cluster of these httpd instances (or some other web server that a language or framework suggests) behind a load balancer or two, and that seems to work for a lot of people. While effective, though, it seems that such a configuration leaves a lot of grunt infrastructure work up to the development or production support team.

Enter the Java EE stack. As the Mollom engineer noted, using an application server like GlassFish gives the developer and support teams quite a bit of infrastructure for free. In addition to what he listed, a full EE stack can also give you clustering/high-availability, monitoring, server management, etc. (Note: GlassFish v2 support all of these. GlassFish v3 does not support clustering, but GlassFish 3.1, which is just about ready to ship, will). Many of the "ancillary things that make big systems work" are provided for you. It’s not free, of course. The system demands are typically higher, and those "ancillary things" have to be configured, tuned and monitored, but they don’t have to be developed, which makes the systems that run on them a fair bit simpler.

It is possible, of course, to get the best of both worlds. Some dynamic languages, like Groovy, already run on the JVM, while projects like JRuby and Jython allow running those languages in a Java EE container, all while still reaping the benefits that dynamic languages offer. For shops that using those languages, or would like to, this is a very compelling option.

Dynamic languages do offer a lot that we Java developers would love to use, but users of those dynamic languages would be well-served to take a good look at the Java EE stack and see if perhaps Java can add value to their deployment.

{/asciidoc}

{#asciidoc} = Adding SCM Branch Information to Your Prompt

UPDATE: I’ve modified the scripts and prompt settings to be a bit more intelligent

Today, a coworker sent me a link to an old blog post about adding git and svn branch information to your prompt. As awesome and helpful as that was, my first thought was, "What about hg support?" followed quickly, if not somewhat embarrassingly, by, "What about CVS support?" Thinking it would be quicker (and more fun) to hack than to google, I added both. The end result is this:

{#asciidoc} = Running a Single JUnit Test

Part of my job as a developer is writing unit tests. Lately, though, I’ve been spending more and more of my time in our tests, which take a long, long time to run. For example, to run the GlassFish Admin Console’s StandaloneTest class, the last run took 17 minutes and 36 seconds. Clearly, something needs to be done to speed that up overall, but I have to wait for the entire class to run just so that I can see if my one new/changed test works. Try as I might, I have not been able to find a way to make the surefire Maven plugin run just that one test method. This morning, though, I happened to stumble across a new feature of JUnit (as of 4.7, if I read correctly) that did the trick for me, which I’ll share here.

{#asciidoc} = Interested in Remote Method Calls via JS in JSF? Jason Lee 2010-09-21

One of the nicest enhancements to the JSF specification that 2.0 brought was the inclusion of native Ajax support. It is now extremely simple to Ajaxify a JSF application. One thing that it lacks, though, is the ability to call arbitrary methods on JSF (or CDI?) Managed Beans. There is a project that offers that kind of functionality, and it’s been around for years: Direct Web Remoting. I’ve used this library at times and have found it to be really useful in certain situations. That got me to wondering, Should this kind of functionality be a first class citizen of JSF? To help us decide, let’s take a quick look at how DWR works.