If you’ve been following my series on using the GlassFish REST interface, you’ve probably noticed that your JSON and XML output isn’t pretty-printed like mine. While there are several online tools that can fix that for you, there’s no need for the extra step. GlassFish will do that for you. Let’s look at how to make that happen.

In previous posts, I’ve shown various ways to manage a GlassFish 3.1 server via its REST interface. As nice as that is, we also support monitoring your server via REST as well. In this article, we’ll take a look at some of the things you can ask of your server.

image::http://glassfish.java.net/image/sparky_3.1_orange.gif[style="float: right; padding: 0px 0px 10px 10px;"] For those that may not have noticed, today the GlassFish team officially released version 3.1. This new release brings in a myriad of features, the most significant of which is probably clustering and high availability. The Aquarium is the best place to find links to blogs, screencasts etc. from various GlassFish engineers (though Markus Eisele has a nice run down of the new features here as well). The Aquarium’s list is pretty extensive, so certainly check it out, but I’d like to highlight a few that I found interesting from teammates of mine:

People often ask what the difference is between the free GlassFish and the commercially-supported version. The answer really is "not much" in terms of the core server itself (pretty much just branding changes). The commercial version, though, has some nice value-add features, such as the Performance Tuner, amongst others.

I’m really, really pleased with how GlassFish 3.1 has turned out. We still (and will always) have more work to do, but this is a solid release that finally fills in some enterprise holes that v3 didn’t have time to fill. Download it, install it, kick the tires a bit, and tell us what you what you think. In the meantime, we’re going to go ahead and get started on 3.2.

From time to time, I’m asked about accessing various EE artifacts (EJBs, etc) from a standalone client. Almost invariably, the user is having trouble getting the environment setup, grabbing an InitialContext, etc. Also almost invariably, my answer to them is "use the application client container", which is as far as I can take them. The topic of application client container, or ACC, came up again recently when I was asked on Twitter about an issue with ACC and GlassFish in a clustered environment. While this user (hi, Markus! : ) figured out his issue before I could be of much help, I took this opportunity finally to learn exactly what the ACC is and how to use it. Thanks to Oracle’s Tim Quinn for his patient and tireless help, here’s what I learned…​

After posting my last entry, GlassFish 3.1, REST, and a Secured Admin User, I was asked about an entry on using GlassFish 3.1’s REST interface with secure admin enabled. Some of you may be asking, "Isn’t that what you just wrote about?" While the titles sound the same, they’re slightly different, but in a very significant way. Let’s take a quick look at secure admin and then see what our REST client needs to do make use of this new server configuration.

In my last post on using the GlassFish REST interface, a commenter asked about how GlassFish handles security. So far, all of my examples have been using GlassFish 3.1 out of the box, which doesn’t require authentication (as a convenience for developers, as well as system admins evaluating the server). In production, of course, the server will be secured, which means our client code will have to be modified. In this installment, we’ll see how that might be done in Java.

Over the past few months, I’ve been posting tips on how to use the REST interface in GlassFish v3 and later to perform various functions. My last post used Scala. In this much briefer and far less ambitious post, I thought I’d share how to deploy an app using curl (from the shell of your choice). If you’re familiar with the REST endpoint, there’s really not just a whole lot new here:

At a recent meeting of the Oklahoma City JUG, I was asked by a member how her group could "script" JSF report generation. After a couple of questions, I figured what she really wanted: she wanted a way to allow users to request reports in an ad hoc manner, as opposed to the reports being run on a schedule. In a general sense, this is a pretty easy question to answer, but I’ve run into situations where the reports take a long time to run — and I’m sure she will, as well — making a web interface for generating the report less useful (due to timeouts, etc). In this entry, we’ll take a look at one way to handle that.

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.