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.

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:

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.

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.

Way back in July, Ed Burns released and announced Mojarra 1.2_15, which is mostly a backport of performance fixes from the 2.0 branch. Given recent changes on the Mojarra team¹, there was some confusion and difficulty getting the jars published to the java.net Maven repository. I’m happy to report, though, that we’ve gotten those kinks worked out, and that this new release of the 1.2 branch of Mojarra is now available for your Mavenized pleasure. Note that this is the Maven 1 repository, and it’s not in central. Those are separate issues on which we’re still working.

¹ Many, many thanks to you, Ryan, for all of your hard work over the years, and best of luck in your new position. :)

Of the many great things about GlassFish, one that is often mentioned most (and is, in fact, what got me involved with GlassFish as an end user years ago) is the Administration Console. It’s an extremely powerful and capable interface, and is, if I may be so bold, orders of magnitudes better than its open source competition (it may even beat commercial competitors, but I have no experience with those). Another powerful tool in GlassFish administration is the asadmin CLI utility, which allows for quick and easy scripting of server provisioning, etc. Did you know, though, that GlassFish has a third administration interface? As of GlassFish v3, we offer a RESTful administration API, based on Jersey, to allow non-Java clients to configure the app server easily. For GlassFish 3.1, one of my main responsibilities, with the help, I should add of my coworkers Ludovic Champenois and Mitesh Meswani, has been to help improve upon the great start we had in in v3. In this entry, we’ll take a look at the current state of the interface and learn the basics of using.

image::https://www.packtpub.com/sites/default/files/imagecache/productview/9522.jpg

Packt Publishing recently released a book titled JSF 2.0 Cookbook, by Anghel Leonard. When I first heard about this book, I was really anxious to get my hands on it. I really like the cookbook concept, so I was excited to see a work in that vein published for JSF. Packt recently sent me a copy to review, so, having read most of the book, here are my thoughts.

First off, I’ll be upfront: I have not read the whole book, but I don’t think that’s a problem. Cookbooks aren’t meant to be read cover to cover, necessarily. While you can certainly do that, these types of books are intended to be a reference. When you have an issue, you look in the table of contents to find the "recipe" that covers your issue, and jump to that page. That’s what I did with this book, mostly. I looked up the recipes for issues I most often have trouble with. I did, though, read almost all of the custom component chapter, as that’s area that holds a lot of interest for me. I’ll give that one special attention in a moment.

Each recipe, follows the same basic pattern. It starts with a basic summary of the problem, then goes in to "Getting ready," "How to do it…​," "How it works…​" and "See also." There are minor deviations along the way, but that’s the basic gist. In the Getting Ready section, the author details how the recipe was created (NetBeans 6.8, Mojarra 2.x, and GlassFish v3, showing the author has great tastes : ), so new users can get a sense of what might help work through the recipe. The How to do it section is pretty detailed, with LOTS of source code. Much of the markup is still using JSP, which is a shame since JSP is all but formally deprecated with JSF 2.0 (Facelets being the de facto standard), but you shouldn’t have any major issues applying what you see to a Facelets page. The How it works section that follows does a great job of explaining…​err…​ how it works, which I think is really important. How to do something is rarely enough. If you understand why to do something and how that something works, you’ll be better equipped in the future for similar, but slightly different issues. This section does a good job of that.

The only area of the book I want to comment on specifically is Chapter 5, Custom Components. Of all the areas in JSF, component authoring has always been a favorite of mine. I am far from being a leading expert, but I’m pretty comfortable with it and really enjoy it. Chapter 5, then, was one of the first things I turned to. The author does a great job of giving a variety of examples using validators, ajax, etc. A big glaring flaw for me, though, was the discussion of the JSF lifecycle, a very important topic for component authors. In the graphic on page 130, encoding is shown as happening in the Apply Request Values Phase, and decoding is shown as happening in the Render Response Phase. Unless I’m sorely mistaken, that’s exactly backwards. Despite that error, the chapter itself is extremely helpful. I would advise, though, that if you are looking to learn component development, to try JavaServer Faces 2.0: The Complete Reference by Ed Burns, and Chris Schalk, or Core JSF by David Geary and Cay Horstmann. That’s not to belittle this book in anyway. The Geary/Hortsmann and Burns/Schalk books are meant for different purposes. JSF 2.0 Cookbook has a slightly different purpose, which is complementary to the first two, and which it does well, I think.

Overall, I think this is a really good book. Though not perfect, it provides a lot of value to the JSF developer. From beginner to expert, I think there is enough in this book to help just about everyone out of a jam from time to time.

Some time ago, I was given a copy of JSF 1.2 Components by Ian Hlavats and asked if I’d write a review for it. It’s long overdue, but here are my thoughts on this book.

In a recent forum post, a user asked how to store a Facelets file in a database. Although JSF doesn’t support this out of the box (though it would be a nice feature), it’s not too difficult to add. In this entry, I’ll show you how to serve Facelets from a JAR file, then give some thoughts that will help, I hope, implement a database-backed approach. I’ll be using JSF 2, so if you’re using Facelets 1.x with JSF 1.2, you’ll have to extend com.sun.facelets classes to make this work in that environment. With that out of the way, unto the breach!

There has been a lot of speculation and concern about the fate of GlassFish after the Oracle acquisition. Yesterday, though, we were able to unveil the official roadmap for GlassFish, and I think it looks very promising. In short, not much is going to change with regard to the open source side of things, though there are some changes on the commercially supported offering, which is not unexpected. Some of the highlights include:

For a more complete picture, see the slide deck here.