Nuxeo Developers Blog

Nuxeo on Glasshfish TV

Glassfish TV tomorrow!

I'll be playing Ed McMahon to Stefan Fermigier's Johnny Carson tomorrow on Sun's Glassfish TV. Well, perhaps one could apologize to Paul Simon and say "you can call me Al" ... of "Stefane Fermigier et al."

We will discussing a number of key areas of interest that are of interest to Nuxeo users/developers, Glassfish users/developers/crustaceans, and general Web ne'er-do-wells:

• Our analysis of the (approximately) two dozen Java web technologies and how they perform under the strain of a transport workers strike.
• Our efforts to reduce the locking costs -and thus increase the number concurrent users served - of our large (>200,000 lines) JSF application, after we have had a few bottles of Beaujolais Nouveau at lunch.
• Maximizing the heat dissapation of a large number of JVM in a small machine room : Reblochon is the answer.
• Our proposal for a new JVM bytecode op that could dramatically increase bandwidth utilization in applications that have complex content negotiation needs: MILD_INTRANSIGENCE_AT_THE_UN.
• Finally, we will give an overview our use of Glassfish and OSGi in the 5.2 RC Release of Nuxeo («une nouvelle de dernière minute») as well as various and sundry ideas that we have that are Java-, Glassfish-, or paté-related for the future of Nuxeo 6, Nuxeo 7, or the heat death of the universe.

Java Management Interface, coming in 5.2 RC1

Credit Where It's Due

This blog post would not have been possible without the diligent and thoughtful assistance of Stéphane Lacoin. Stephain gave me the big clues on how to configure the current Nuxeo 5.2 "head" to make all the JMX stuff "turn on" and also personally tracked down and squashed a number of bugs that made this article possible (including one in JBoss!). Somebody, please give that man a croissant!

Not Quite in 5.2.0.m4

This blog post is about a feature that did not quite make it into the 4th milestone release of Nuxeo 5.2. It is in the current source code build (or you can get it from the nightly snapshots) but I thought those that are waiting for the release candidate release might be interested to see what's "coming down the pike." As of the time of this writing, it is expected to be in the 5.2 RC1 release.

JMX: The Java Management Extensions

The Java Management Extensions or JMX debuted with Java 1.5. These extensions allow an client application to manage and monitor a collection of devices, computers, and services. A simple example might be a three-tiered web application, deployed on three separate servers. One would like to all the feedback for monitoring sent to a single place, often called the management client, where a human can look at the incoming data or the management client itself can process the data with some type of analysis procedure. The data from a three-tiered web application would include data from all the software layers such as database, application server, and application itself, but might also include reports from the network connecting the layers, and some type of hardware monitoring daemons as well. Once this has been analyzed, by a human, computer, or both, then one may want to take some time of actions to manage the objects being monitored; in the example of the three-tiered application one can easily a imagine a scenario where you would want to begin an orderly shutdown procedure. Coordinating all the layers of software, on different machines, to do this gracefully is clearly a management problem!

Configuring Nuxeo

You need to install one extra bundle into your build of Nuxeo 5.2 to get this to work, the bundle is nuxeo-runtime-management. You should put the bundle in <nuxeo-install-dir>/server/default/deploy/nuxeo.ear/plugins. Nuxeo is smart enough to "pick up" this additional modules and its features the next time you fire it up just because it is present. So, go ahead and restart (or start) your server with the script bin/run.sh (or run.cmd for windows).

Connecting JConsole to the running Nuxeo

With Nuxeo now running and exposing its management interfaces you need to hook up a JMX client to see what's going inside the Nuxeo system. You can do this with the program "jconsole" that is supplied with the Java development kit (at least if you got your JDK fairly recently). When you fire it up, you'll need to enter these three values:

The first one is the tricky one, obviously! The hostname of the machine running nuxeo in this example is "localhost" and the nuxeo server, at the time of this writing, exposes its java management interface on port 2009. Normally, the nuxeo server does not require a username and password, the second and third values, since the management service is "turned off" by default and you have to turn it on by installing bundles.

Getting information about the system state

Once you have connected, you will see the set of mbeans (management beans) that are exposed by Nuxeo:

When you drill down into a category you can get statistics about the objects in that category. In the previous screenshot, for example, if you click on the "metric" you will get information about the number of http sessions that have been created and destroyed while the nuxeo server is running. Also shown in the previous screen shot is the "probe" mbean. This mbean does a probe of the repository periodically (about every 30 seconds) and keeps track of the successes and failures. Here's what you would see if you drilled down into that item:

So, from this display you can see that the probe has been run 25 times without failures and the last probe took 111 milliseconds.

Running Methods

You can not only see data with the JMX interface to Nuxeo, but you can execute management functions as well. For example in the previous screen shot, if you click on the "Operations" button you will be presented with a list of methods that you can execute from the management interface. One of these is "disable" that you can use to turn off the probe behavior. When you run a method via the management interface, normally you get a message like this:

More fun, though, is to map the Nuxeo Runtime's inventory with the RuntimeInventory's factory object. You can click on that object (shown in the upper left) of the probe screenshots under category "nx" then category "Runtime" inventory. You will have your choice of a number of methods on that screen that give information about your system, but the most interesting one is "bindTree". The result of clicking this button to invoke that method is shown in this screenshot:

This takes all the bundles and components that the runtime knows about and makes them available via the JMX interface, so you can get some statistics about them, although in many cases this is quite minimal. You can, of course, unbind that tree of objects with "unbindTree" as shown in the screenshot above.

Getting audited isn't all bad...

Athough it's getting perilously close to tax day for our friends in the United States (tax days come in September in France), we are going to bring up the subject of auditing anyway. Many of the actions that users peform when using Nuxeo are audited (assuming you have deployed the auditing bundle) and some summary statistics can be seen via the JMX interface. The following screen shot gives you a feeling for what types of actions can be seen via the NXAuditService category:

The JMX interfaces are a nice way to interact with enterprise software systems like Nuxeo and not only keep an eye on how they are running but also perform many basic management functions. This is going to be a standard feature of Nuxeo starting with the 5.2 GA release and you can expect that we will gradually be exposing more functionality through JMX is we go forward.

If you have questions or comments about Nuxeo and JMX, or this article, drop me a note at ismith [at] nuxeo [point] com. We would especially love to hear from folks who have specific needs for functions to be exposed by Nuxeo through the management interface.

Two more soldiers down

Double your pleasure, Double your fun

This has been a busy week on the book front and general purpose Nuxeo chicanery. I've got a number of things cooking right now so that I can show off features of the platform. Both of these features are of the "should be available to the public soon" type, so I've had to actually garner time from the developers to get them to give me demos and let me capture screenshots. I hope both of those posts are available tomorrow. I have the text of one written and the other should not be a major hurdle.

I've completed two more chapters, one fairly short one about XMap and Apache Commons Logging. I think it's only fair to admit that I really dislike Apache Commons Logging beacuse it gives people the distinct idea that writing more logging frameworks is ok. I can't believe the Apache Foundation green-lighted a meta-framework for logging when they already had log4j. Oh well. The other part of the short chapter is about the XML un-pickling code we use, which is packaged up into the library XMap. We use this all over the place in nuxeo to read in snippets of XML and turn it into Java objects.

The more meaty chapter is about Users and Groups. I got a lot of help, particularly on understanding directories and the test infrastructure needed for UserManager, from Anahide T. Big props to her! In this lesson, we construct a new class that interacts with the UserManager to create a new Group. Although it doesn't do that much, there is quite a bit to working with the UserManager service because of the wide variety of situations in which Nuxeo can be deployed. We have to work with flat text files, databases of user records of all sorts, and LDAP to be good enterprise citizens. I think that folks that read this chapter will come away realizing, more than anything, that messing around with users and groups in a big organization is serious business!

As always, the whole text can be found at http://www.nuxeo.com/static/book-draft.

Selenium and Ajax Requests

Following Lance Ivy's excellent post (http://codelevy.com/articles/2007/11/05/selenium-and-ajax-requests), here's an easy way to write Selenium tests for Ajax requests when you're not using Prototype directly, but using Ajax4JSF or RichFaces.

Add this to your user-extensions.js:

/**
 * Registers with the a4j library to record when an Ajax request
 * finishes.
 *
 * Call this after the most recent page load but before any Ajax requests.
 *
 * Once you've called this for a page, you should call waitForA4jRequest at
 * every opportunity, to make sure the A4jRequestFinished flag is consumed.
 */
Selenium.prototype.doWatchA4jRequests = function() {
 var testWindow = selenium.browserbot.getCurrentWindow();
 // workaround for Selenium IDE 1b2 bug, see
 // http://clearspace.openqa.org/message/46135
 if (testWindow.wrappedJSObject) {
   testWindow = testWindow.wrappedJSObject;
 }
 testWindow.A4J.AJAX.AddListener({
  onafterajax: function() {Selenium.A4jRequestFinished = true}
 });
}

/**
 * If you've set up with watchA4jRequests, this routine will wait until
 * an Ajax request has finished and then return.
 */
Selenium.prototype.doWaitForA4jRequest = function(timeout) {
 return Selenium.decorateFunctionWithTimeout(function() {
  if (Selenium.A4jRequestFinished) {
   Selenium.A4jRequestFinished = false;
   return true;
  }
  return false;
 }, timeout);
}

Selenium.A4jRequestFinished = false;

Instead of using pauses or waitForCondition (writing some esoteric javascript test to detect that the Ajax call ended), you can then write something as simple as:

<tr>
 <td>watchA4jRequests</td>
 <td></td>
 <td></td>
</tr>

... (command triggering the ajax call) ...

<tr>
 <td>waitForA4jRequest</td>
 <td>10000</td>
 <td></td>
</tr>
</pre>

For Selenium beginners, the Javascript code has to be placed in a file named user-extensions.js and passed as an attribute to the Selenium Server command line option "-user-extensions <file>". When using Selenium IDE, it can be set in the options menu (don't forget to close the IDE and restart it for this to be taken into account).

Cross validation with jsf

I'm happy to have found an elegant (and easy) way to handle cross-validation of JSF components. The idea is to add an hidden input and bind it to a validator, passing component ids to validate as attributes:

<h:inputHidden value="needed" validator="#{myBean.validatePassword}">
   <f:attribute name="firstPasswordInputId"
     value="#{layout.widgetMap['firstPassword'].id}" />
   <f:attribute name="secondPasswordInputId"
     value="#{layout.widgetMap['secondPassword'].id}" />
</h:inputHidden>

Note that here, component ids are retrieved from the layout widget ids, but any id bindings will do (taking example on what's done when adding a "for" attribute to a h:message tag for instance).
Note also that the hidden input has to be placed after the referenced components in the page, so that they have been validated, and had their local values set.
The "needed" value is just here because the tag requires its "value" attribute to be set on my box, even if it's useless for us.

The validation method can then retrieve the components values:

public Object retrieveInputComponentValue(UIComponent anchor, String componentId) {
    Map attributes = anchor.getAttributes();
    String inputId = (String) attributes.get(componentId);
    UIInput component = (UIInput) anchor.findComponent(inputId);
    return component.getLocalValue();
}

public void validatePassword(FacesContext context, UIComponent component, Object value) {
    Object firstPassword = retrieveInputComponentValue(component, "firstPasswordInputId");
    Object secondPassword = retrieveInputComponentValue(component, "secondPasswordInputId");
    if (!firstPassword.equals(secondPassword)) {
        FacesMessage message = new FacesMessage(FacesMessage.SEVERITY_ERROR, "Password mismatch", null);
        throw new ValidatorException(message);
    }
}

Note that all components have to be in the same container for this to work properly as is (UIComponent#findComponent method restricts its search to the nearest container). Of course, this retrieval method can be adapted to handle more tricky situations, or to handle other kinds of component types.

What's the improvement compared to what i've seen so far? Well I've seen recommendations to use an hidden input too, but it's retrieving the referenced components values binding the components to some fields in the backing bean. So in this case, you had to add getters and setters for each component, and you had to do it for every set of components following the same validation criterion on a given page. Other recommendations involved writing a custom component handling several other ones, assuming dependent components will be rendered in the same part of the page... overkill, right?

In other words, here you can perform the same validation several times in the same page... with less code.

And it's prettier ;-)

Events, both real and imagined

Another week, another chapter?

Yeah, I know I said I'd be releasing these chapters every day or so, but sometimes things go astray. I had a rough week with a lot of immigration into France problems (for my dog! my wife didn't have any) as well as having to install my "world" on yet another machine. I've got through an old mac, a big server in the amazon cloud, and I'm now using my desktop remotely (via the old mac) on some huge 8 way server in a Nuxeo machine room. Sigh. Anyway, that setup is performing pretty well so I should be out of the woods now until my new macbook comes. (Air! Will somebody give me an Air, puh-leeze?)

This installation is nominally about Events and Event Handling--but secretly there is a agenda! I wanted to introduce readers to all of the tricks involved in getting eclipse to work well for testing but I did't want to do it in a chapter where the content itself was super-tricky. So, I figured most Java developers know about Events and Event Handling (since this used everywhere else) and it would be a good place to introduce the "Eclipse for testing, Maven for deploying" mantra that I'm using in the book.

So, here it is in all it's glory, chapter 8, Events and Event Handling.

The whole book can be found here.

It's only fair to admit that Alexandre Russel helped me a ton on this chapter--he re-introduced me to the idea of Eclipse's source path. I, foolishly, thought that a source path should contain, you know, "java source code." Oh, no, no! The "source path" in Eclipse can be better named "Places where the content will be copied into eclipse's designated output folder, unless it is Java source code, in which case we will compile it and then put the compiler OUTPUT in the designated output folder." I guess that was hard for them to fit on the menu item.