mult.ifario.us

According to the greeting card companies, October 16 was Boss's Day. I don't have a boss the rest of the time, but I decided to get one for the occasion.

In an earlier entry, I commented on an IllegalStateException that can occur when the SAX NamespaceSupport helper class is used incorrectly. (A common scenario for this exception to occur is a newer set of SAX APIs and an older parser, e.g., Crimson, but any code that used NamespaceSupport to track namespaces is susceptible.) I also offered some suggestions about proper usage of NamespaceSupport for writing SAX handlers, but those suggestions were incorrect for the current version of NamespaceSupport.

As the Javadocs for the current version of the class state, it is intended for use by parsers as a convenience between when the start of an element is detected while scanning the input and when the startElement event is generated. Put another way, the lifecycle of a stack frame in NamespaceSupport is the lifetime of a startElement event in the parser, while the desired lifecycle of a set of namespace declarations for the purposes of a handler spans from the start element that declares the namespaces (and inherits their predecessors) to the end element that moves them out of scope.

Thus, the better practice is:

Do not use NamespaceSupport to track namespace bindings in a SAX handler implementation.

Instead, you'll have to use something like this.

Boris Lublinsky, a fellow Chicagoan and WS-guy, has an overview article in this month's Business Integration Journal. I assume that the second part will be out next month.

Update: I thought about this a little bit more (and did some experimentation), and some of what I said below is wrong. See a more recent entry for an update.

You never know which SAX you're going to get. For example, on my PowerBook, I get the version from the 1.4.2 JDK by default, and that (according to the source, at least) is SAX 2.0r2pre. Using Xerces 2.6.2, I get SAX 2.0.1.

The difference is an IllegalStateException if a NamespaceSupport instance is used incorrectly, but proper hygeine ensures portable (and correct) behavior. A short digression on how SAX deals with namespaces is in order.

No matter how you set the SAX namespace properties, if namespaces are enabled, you'll get startPrefixMapping and endPrefixMapping events. The startPrefixMapping events occur immediately before a startElement event, and endPrefixMapping events occur immediately after a endElement event. The startPrefixMapping and endPrefixMapping events don't necessarily occur in a particular order or in a nested pattern. (By the way, you care about prefix mappings separately from element and attribute names if you're working with QNames in attribute values or element content, e.g., in many XML schema-typed documents.)

In a nutshell, the guideline for NamespaceSupport is:

Namespaces should only be declared on a fresh stack frame. Specifically, the order of operations for a NamespaceSupport instance is declarePrefix invocations, processName (or other) invocations, and finally pushContext.

Here's why. If you put some code like this in your ContentHandler implementation:

private NamespaceSupport _nss;

public void startPrefixMapping(String prefix, String uri)
    throws SAXException
{
  _nss.declarePrefix(prefix,uri);
}

You'll be pushing namespace bindings onto the current stack frame within the NamespaceSupport instance, and all of this will happen before the startElement event.

SAX 2.0r2pre was more permissive, but SAX 2.0.1 "locks" the NamespaceSupport instance once it is used to resolve a name through the processName() method. So, if you call pushContext() too soon and someone calls processName(), the stack frame will be "locked" when the next startPrefixMapping event shows up, resulting in an IllegalStateException. Thus, in the code for the startElement event, the last thing to touch the NamespaceSupport should be _nss.pushContext() to create a fresh frame for the next round of startPrefixMapping events.

This is perfectly reasonable, since adding prefix bindings might change the way a qualified name's parts would resolve.

By the way, you don't really need to pay attention to the endPrefixMapping events unless you want to check up on the parser or event generator. Instead, just implement the endPrefixMapping method with an empty body and ensure that a _nss.popContext() is the last thing in the endElement implementation that touches the NamespaceSupport.

I came across a FileNotFoundException inside a File.createTempFile() call in an otherwise thoroughly tested piece of code running in a fresh Tomcat (5.0.19) today, and I had to scratch my head for a moment. It turned out that the file that did not exist was the directory specified by the java.io.tmpdir property! The setting was Tomcat-specific but not created explicitly by Tomcat. (Baaaaad kitty...) I arrived at and tested this conclusion without the use of a debugger, but the only way to catch it otherwise would have been to actually step through the innards of the method in the File class.

I'm surely not the first person to stumble on this one, but I didn't find it in the Tomcat changelog or bug database. So I filed a bug report.

Update: Rémy Maucherat pointed out that Tomcat's temporary directory is there when the distribution is unpacked, so while I can affirm that the code runs outside of Tomcat without deleting /tmp, $CATALINA_HOME/temp is getting deleted at some point.

Thus, this is more of a generic troubleshooting consideration than something specific to Tomcat:

The JVM makes no guarantees that the directory specified by java.io.tmpdir exists, and a FileNotFoundException inside a File.createTempFile() call may be attributable to a missing temporary working directory.

The important thing for people to realize is that both individually and collectively, the WS-* specifications are a work in progress. Wwork is ongoing by vendors, by end-users, by thought leaders, to figure out what is important (i.e., useful) through a mixture of implementation and experimentation.

A new specification should be looked at as a proposed experiment. The experiment should be based on a set of well-considered hypotheses and motivated by practical experiences. The history of the accepted standards in the space (e.g., the evolution of SOAP from the initial proposal to the refinements outlined by the WS-I Basic Profile) bears this out, and other experiments (e.g., BPEL4WS 1.1 becoming WS-BPEL 2.0) are being tempered by implementers and collective discussion. The questions in my mind are not so much about establishing the fundamental and forever immutable tenets of Web Services — always an impossible task for any effort — but rather about ensuring that the experiments that we are investing in are properly conceived, controlled, and executed.

An early draft review of the JSR-208 a.k.a. JBI (Java Business Integration) is available for download. In a nutshell:

"JBI seeks to address this problem [vendor-specific integration soup] by creating a standards-based architecture for integration solutions, allowing third-party components to be assembled by the end user."

The key high-level constructs of JBI are:

• An environment is a container that provides a normalized WSDL-based messaging service ("NMS"), deployment, (re)configuration, deployment, and management.
• A service engine ("SE") is a "business logic driver". (This is where WS-BPEL fits into JBI.)
• A binding component ("BC") is a bridge between the internal normalized messaging service of the JBI environment and external protocols such as HTTP or JMS.

In terms of a WS-BPEL process living in a JBI environment, the process would be deployed in a SE that can execute WS-BPEL processes againt the NMS, and the concrete bindings for partnerLinks would be BC implementations.

One of the reasons that I'm excited about JBI is a little bit selfish: the portable runtime container that we built for PXE is similar to a JBI environment, so we've already been working in these terms for over a year... PXE will be available as a JBI component as soon as there are implementations that can host it.