Pleasing the Crowds, Improving IoC, Extending the Community

I've been quite busy of late: a nearby Tapestry 4 project to pay the bills, a bunch of chances to talk to crowds about Tapestry 5 (in Philadelphia, Minneapolis and at home in Portland, Oregon).

I've significantly changed my Tapestry 4 presentation; it now highlights the BeanForm component, then the Table component and lastly Trails. I'm showing the high end of what's possible in Tapestry, rather than showing people the gory little details up front. That usually gets their attention.

I then show what's going on in Tapestry 5 and that really get's peoples jaws dropping. People crave this. They want to use it today. That is the desired effect. Case-insensitive, pretty URLs. Live class reloading. No XML. Incredible performance. Best of breed exception reporting. And we've barely gotten started yet.

I've been busy: Guice has set a high bar for IoC containers, but it still doesn't have certain features that Tapestry is dependent upon. That hasn't slowed me from taking the best ideas from it. Tapestry 5 now has a similar approach to autobuilding, and in most cases, a Tapestry service no longer needs a service builder method. Instead, a module can define a static bind() method and use the ServiceBinder to tell Tapestry about service interfaces and service implementations: Here's an example from the Tapestry module itself:

    public static void bind(ServiceBinder binder)
    {
        binder.bind(ClasspathAssetAliasManager.class, ClasspathAssetAliasManagerImpl.class);
        binder.bind(PersistentLocale.class, PersistentLocaleImpl.class);
        binder.bind(ApplicationStateManager.class, ApplicationStateManagerImpl.class);
        binder.bind(
                ApplicationStatePersistenceStrategySource.class,
                ApplicationStatePersistenceStrategySourceImpl.class);
        binder.bind(BindingSource.class, BindingSourceImpl.class);
        binder.bind(TranslatorSource.class, TranslatorSourceImpl.class);
        binder.bind(PersistentFieldManager.class, PersistentFieldManagerImpl.class);
        binder.bind(FieldValidatorSource.class, FieldValidatorSourceImpl.class);
        binder.bind(ApplicationGlobals.class, ApplicationGlobalsImpl.class);
        binder.bind(AssetSource.class, AssetSourceImpl.class);
        binder.bind(Cookies.class, CookiesImpl.class);
        binder.bind(Environment.class, EnvironmentImpl.class);
        binder.bind(FieldValidatorDefaultSource.class, FieldValidatorDefaultSourceImpl.class);
        binder.bind(RequestGlobals.class, RequestGlobalsImpl.class);
        binder.bind(ResourceDigestGenerator.class, ResourceDigestGeneratorImpl.class);
        binder.bind(ValidationConstraintGenerator.class, ValidationConstraintGeneratorImpl.class);
        binder.bind(EnvironmentalShadowBuilder.class, EnvironmentalShadowBuilderImpl.class);
        binder.bind(ComponentSource.class, ComponentSourceImpl.class);
        binder.bind(BeanModelSource.class, BeanModelSourceImpl.class);
    }

The ServiceBinder interface is fluent, we could follow on with .withScope(), .withId() or .eagerLoad() if we wanted. In most cases, defaults from there are sensible or come from annotations on the implementation class (and therefore, rarely need to be overridden).

The primary mechanism for injection is via constructor parameters. In general, annotations are not necessary on those parameters any more, and Tapestry will find the correct object or service automatically (primarily by matching on parameter type).

Service builder methods are still useful for when a service involves more than just instantiating a class, such as registering it for some kind of notification from another service:

    public ComponentClassResolver buildComponentClassResolver(ServiceResources resources)
    {
        ComponentClassResolverImpl service = resources.autobuild(ComponentClassResolverImpl.class);

        // Allow the resolver to clean its cache when the source is invalidated

        _componentInstantiatorSource.addInvalidationListener(service);

        return service;
    }

The autobuild() method will construct an instance, performing necessary injections. We can then perform any additional realization before returning it.

The end result has been to simplify and minimize the amount of code in the module builder classes.

Tapestry IoC now supports services that do not have a service interface; the actual type is used as the service interface and the service is not proxied: it is created on first reference and can't have interceptors. Normal services are proxied on first reference, and only realized (converted into a full service with a core service implementation and interceptors) on first use (the first method call).

In a step away from the code, we are running a vote to add Dan Gredler as a Tapestry committer. I expect that to run successfully, and I also expect to add a few more people to the roles soon.

I'm getting very excited. Things are coming together nicely (but never fast enough).

Ouch! VMWare Fusion is not compatible with VMWare Player

Turns out that VMWare Fusion, the VMWare for Mac OS X, creates an image that isn't compatible with the VMWare player on Windows. This is why I'm happy I do test runs, but it does mean I have to spend another few hours recreating my workshop environment on Windows, using VMWare Workstation. So much for catching a movie tonight, or leaving the house tomorrow.

Hopefully this is something that'll be corrected in a later release.

Tapestry 5 at JavaOne and OSCON

My session at JavaOne has been scheduled:

BOF-6563: Tapestry 5: Java Programming Language Power, Scripting Ease
Esplanade 307-310
May 9 20-07, 8:55pm

In addition to JavaOne and NFJS, I've also been accepted to speak again at OSCON this year. I'm looking forward to spreading the Tapestry 5 message and meeting people using Tapestry, as always!

More Servlet Spec Wish-List Ideas

I'm thinking back to an earlier post about Servlet Spec 2.5 and what's missing.

Here's a few more ideas, based on implementing Tapestry 5 and other things besides. My previous ideas still stand.

web.xml introspection: It would be great to know what's going on inside web.xml. An API to query the web.xml meta-data and learn the names and mappings of the other servlets and filters would be great. Tapestry 5 acts as a filter and it would be handy if it could know what other servlets were in the WAR to help it decide whether to process a URL as inside Tapestry, or let another servlet handle it.

Event registration: Many of the listeners possible with the servlet API only apply to objects created by the servlet container's brain-dead IoC container. If my code needs to recerive notifications as a say, HttpSessionAttributeListener, I currently have to put together a Rube Goldberg machine in order to receive those notifications. There should be an API, perhaps attached to the ServletContext object, for registering for such notifications.

Quality of Service: Currently we have single server or clustered. Single server is not scalable beyond a certain point. Clustered causes a lot of problems managing data and introduces lots of overhead in terms of copying session attributes around the cluster.

I would like at least one additional level of service: non-replicated cluster. It assumes sticky sessions such that all requests for a given session are handled by a single box within the cluster. If that box fails, then future requests will be sent to a different box within the cluster, and the application will receive a notification that data has been lost.

Really, most non-financial applications can survive a rare loss of data midway through a session, and having this intermediate service level would allow the vast majority of applications to scale much, much higher than is possible today. I've previously implemented something like this by storing an object in the HttpSession that contained a Map in a transient variable.

Concurrency documentation: Many objects in the Servlet API are shared between threads (ServletContext, HttpSession) and it would be good form, and very useful, to know the proper semantics there. Futher, there needs to be better documentation for application and framework developers about the implications thereof.

In light of what I've learned about the Java Memory Model from Brian Goetz (and his book, Java Concurrency in Practice) any non-synchronized access to a shared object, say a mutable object stored into the HttpSession, is suspect: a potential source of scary, non-reproduceable, intermittent concurrency bugs.

Should all methods of such objects be synchronized? Can the servlet container acquire a lock when the HttpSession is accessed and hold it for the application for the remainder of the request (that would be handy!). Could there be an API for allowing the framework/application to manage access to HttpSession variables?

It's clear that the HttpSession API was designed to store small, immutable objects such as Strings and Integers. It is also clear that most applications don't use it this way (though Tapestry is a little better because it mostly stores individual page fields in the session, which are often small immutables, whereas most frameworks and applications store more complex state holding mutable objects).

... well, I've run out of steam, but I'll be racking my brains for more ideas like these.

Tapestry 5 IoC from a Guice Perspective

So Guice has a few good ideas, and with Tapestry 5 still in a fluid state, I've absorbed a few of them into Tapestry 5 IoC. At the core, is the key ObjectProvider interface:

public interface ObjectProvider
{
    <T> T provide(Class<T> objectType, AnnotationProvider annotationProvider, ServiceLocator locator);
}

Implementations of this interface plug into a chain-of-command within Tapestry and, via the AnnotationProvider, can query for the presence of annotations to help decide exactly what is to be injected. A lot of Guice's examples, things like the @Blue service, are easily replicated in Tapestry 5 IoC, there's just not a lot of need for it. I supposed it would look something like:

public class BlueObjectProvider {
  private final Map<Class,Object> _blueObjects;

  public BlueObjectProvider(...) { ... }

    <T> T provide(Class<T> objectType, AnnotationProvider annotationProvider, ServiceLocator locator) {
      if (annotationProvider.getAnnotation(Blue.class) == null) return null;

      return objectType.cast(_blueObjects.get(objectType));
  }
}

Implicit here is a service configuration of implementations, keyed on object type, used when the @Blue annotation is present. Here's what the module would look like:

public class BlueModule {

  public ObjectProvider buildBlueProvider(Map<Class, Object> configuration)
  {
    return new BlueObjectProvider(configuration);
  }

  public void contributeMasterObjectProvider(
    @InjectService("BlueProvider") ObjectProvider blueProvider,
    OrderedConfiguration<ObjectProvider> configuration) {
    
    configuration.add("Blue", blueProvider);
  }

  public void contributeBlueProvider(MappedConfiguration<Class, Object> configuration,
    @InjectService("MyBlueService") Service myBlueService) {
    configuration.add(Service.class, myBlueService);
  }
}

public class OtherModule {

  public OtherService build(@Inject @Blue Service service) {
    return new OtherServiceImpl(service);
  }
}

On the one hand, this is more verbose, since its somewhat more procedurally based than Guice's approach, which is pattern based. On the other hand, it demonstrates a couple of key features of Tapestry 5 IoC:

• Service construction occurs inside service builder methods; there's no layer of abstraction around service instantiation, configuration and initialization ... you just do it in Java code. There simply isn't a better language for descibing instantiating Java objects and invoking Java methods than Java itself.
• Dependency injection is a concern of the module not the service implementation. The special annotations go in the module class, and the service implementation class is blissfully unaware of where those dependencies come from or are identified and obtained.
• Dependencies are passed to the service builder methods, which do whatever is appropriate with those dependencies; in many cases, the dependencies are not passed to the instantiated class, but are used for other concerns, such as registering the new service for event notifications from some other service.
• The contributeBlueProvider() method can appear in many different modules, and the results are cumulative. This allows one module to "lay the groundwork" and for other modules to "fill in the details". And, again, if this style of injection ("flavored" with the annotations) really became popular, it would be easy to integrate it into the central Tapestry 5 IoC module so it could be leveraged everywhere else.

In fact, in the OtherModule class, you can see how the injection lays out once the groundwork is prepared: Just an @Inject qualified with @Blue and you're done. Again, I can't emphasize enough how well moving construction concerns into the service builder methods works; it gives you complete control, it's unit testable in a couple of different ways, it keeps the service implementations themselves clean (of dependencies on the IoC container -- even in the form of annotations). It also keeps explicit what order operations occur in. HiveMind chased this with ever more complex XML markup to describe how to instantiate, configure, and initialize services.

That last feature, the interaction of multiple modules discovered at runtime, is the key distinguishing feature, and the one that's hardest to grasp. For me, it is the point where an IoC container transitions from an application container to a framework container. In an application container, you explicitly know what modules are present and how they will interact. It's your cake, starting from raw flour, sugar and eggs. Nothings in the mix that you didn't add yourself.

With HiveMind and Tapestry 5 IoC, the goal is to build off of an existing framework, and its interwoven set of services. The framework, or layers of framework, provide the cake, and you are trying to add just the icing. Configurations are the way to inject that icing without disturbing the whole cake, or even knowing the cake's recipe.

So Guice is a good kick in the pants, and Tapestry 5 IoC has evolved; the old @Inject annotation, which used to include a string attribute to name the thing to inject, has been simplified. The @Inject annotation is still there, but the string part is gone. Tapestry primarily works from the object type to match to the lone service implementing that interface. When that is insufficient, there's the MasterObjectProvider and Alias service configurations, which provide plenty of room to disambiguate (possibly by adding additional annotations to the field being injected).

The big advantage is type safety; refactor the name of a service interface and you'll see little or no disruption of the service network, because dependencies are almost always expressed in terms of just the (refactored) service interface, rather than any additional layer of "logical name".

I think there's a growing issue with Google-worship. It was interesting and disturbing to see so many people announce "Spring is dead! Long live Guice!" on various blogs (and I'll even admit to a little envy ... how come Tapestry 5 IoC doesn't generate this kind of interest?). Guice itself is pretty useless by itself, just as Spring's IoC container is, by itself, useless. The value of Spring is in what's built on top of the container: Wrappers for JDBC, Hibernate, JPA, JMS and every other acronym you can name. Transaction support and interceptors. And, more recently, the really solid AspectJ layer. If Guice wants to be a Spring-killer, or even a real player in the IoC space, it needs to embrace and extend Spring: make it easier to use those Spring integrations than it would be using Spring natively.

Ruby script for creating new Tapestry 5 projects

One thing with building lots of demos for upcoming presentations, labs, & etc. is that I'm having to use mvn archetype:create a lot and that command line is just hideous.

So I took a deep breath, stepped back, and wrote a Ruby script, newproj to simplify the process:

#!/usr/bin/ruby

require 'getoptlong'

opts = GetoptLong.new(
  [ "--group", "-g", GetoptLong::REQUIRED_ARGUMENT ],
  [ "--artifact", "-a", GetoptLong::REQUIRED_ARGUMENT ],
  [ "--package", "-p", GetoptLong::OPTIONAL_ARGUMENT ],
  [ "--version", "-v", GetoptLong::OPTIONAL_ARGUMENT ]
)

group = nil
artifact = nil
package = nil
version = "1.0.0-SNAPSHOT"
error = false

begin
  opts.each do | opt, arg |
    case opt
      when "--group" 
        group = arg
      when "--artifact" 
        artifact = arg
      when "--package" 
        package = arg
      when "--version" 
        version = arg
    end
end
rescue GetoptLong::Error
  error = true
end

if error || ARGV.length != 0 || group == nil || artifact == nil
  puts "newproj: --group groupId --artifact arifactId [--package package] [--version version]"
  exit 0
end

package = package || "#{group}.#{artifact}"

command = "mvn archetype:create -DarchetypeGroupId=org.apache.tapestry -DarchetypeArtifactId=quickstart -DarchetypeVersion=5.0.3"
command << " -DgroupId=#{group} -DartifactId=#{artifact} -DpackageName=#{package} -Dversion=#{version}"

puts command

Kernel::exec(command)

I'll eventually add to this; it needs the option to control the mvn -o (offline) flag, and further in the future, the ability to choose the correct archetype (once we add more than just quickstart). But this sure beats copying and pasting out of the documentation, like I've been doing.

Q: What's your toughest coding challenge? A:...

I've seen this question before on resumes and other people's blogs. I've never had a specific example that worked well. Previously, I've had vague stories of struggling with, say, Javassist ... but the best story here would involve my own code.

A few weeks ago, I noticed that some of my tests, the integration tests, didn't run very well on the Tapestry Bamboo server (our continuous integration server). Occasionally, even when developing on my Mac, I'd see these anomalous errors.

When things work in unit tests and fail in integration tests, one of the first places to look is for concurrency issues. Tapestry has a lot of code related to concurrency: synchronizing, caching, clearing of caches, on-demand instantiation, the works.

I started seeing things that made me question Java reality. For instance, this method is only invoked from a dynamic proxy, from a synchronized method, and the proxy only invokes the method once, yet I was seeing multiple calls:

public class OneShotServiceCreator implements ObjectCreator
{
    private final ServiceDef _serviceDef;

    private final ObjectCreator _delegate;

    private boolean _locked;

    public OneShotServiceCreator(ServiceDef serviceDef, ObjectCreator delegate)
    {
        _serviceDef = serviceDef;
        _delegate = delegate;
    }

    /**
     * We could make this method synchronized, but in the context of creating a service for a proxy,
     * it will already be synchronized (inside the proxy).
     */
    public Object createObject()
    {
        if (_locked)
            throw new IllegalStateException(IOCMessages.recursiveServiceBuild(_serviceDef));

        _locked = true;

        return _delegate.createObject();
    }

}

The code that calls this looks something like:

private synchronized SomeService _delegate()
{
  if (_delegate == null) {
    _delegate = (SomeService) _creator.createObject();
    _creator = null;
  }

  return _delegate;
}

You can see how this would tend to drive you a bit crazy. Eventually, I realized what was going on ... sometimes a runtime exception (an OutOfMemoryError) would be thrown, so the proxy would never complete _delegate(), and would (later, possibly in a different thread), re-invoke this the createObject() method ... and fail, because the lock was set. Solution:

     */
    public Object createObject()
    {
        if (_locked)
            throw new IllegalStateException(IOCMessages.recursiveServiceBuild(_serviceDef));

        // Set the lock, to ensure that recursive service construction fails.

        _locked = true;

        try
        {
            return _delegate.createObject();
        }
        catch (RuntimeException ex)
        {
            _log.error(IOCMessages.serviceConstructionFailed(_serviceDef, ex), ex);

            // Release the lock on failure; the service is now in an unknown state, but we may
            // be able to continue from here.

            _locked = false;

            throw ex;
        }

    }

I also started seeing bizarre error messages, like: Unable to resolve page 'MyPage' to a component class name. Available page names: Start, MyPage, YourPage.. What the hell was going on there ... was something modifying the underlying CaseInsensitiveMap? But the access methods are synchronized.

Once you start seeing bizarre concurrent behavior, and after listening to a few Brian Goetz talks about concurrency (not to mention his great book) ... well, you can start getting paranoid. Maybe its a bug in the JVM (trust me, it's never going to be a bug in the JVM). Maybe I'm not understanding access to effectively immutable objects outside of synchronized blocks (that's a bit more reasonable).

Then I saw something even more bizarre:

    public  T getService(String serviceId, Class serviceInterface, Module module)
    {
        notBlank(serviceId, "serviceId");
        notNull(serviceInterface, "serviceInterface");
        // module may be null.

        ServiceDef def = _moduleDef.getServiceDef(serviceId);

        if (def == null) throw new IllegalArgumentException(IOCMessages.missingService(serviceId));

        if (notVisible(def, module))
            throw new RuntimeException(IOCMessages.serviceIsPrivate(serviceId));

        Object service = findOrCreate(def);

        try
        {
            return serviceInterface.cast(service);
        }
        catch (ClassCastException ex)
        {
            // This may be overkill: I don't know how this could happen
            // given that the return type of the method determines
            // the service interface.

            throw new RuntimeException(IOCMessages.serviceWrongInterface(serviceId, def
                    .getServiceInterface(), serviceInterface));
        }
    }

See the comment about how that code is not reachable? It was reached! It took a while, but I found out that sometimes I was getting back the wrong ServiceDef object out of the ModuleDef. Rarely, but sometimes.

Then it struck me ... all of this strange behavior was traced to my CaseInsensitiveMap implementation. Sure it has a 100% code coverage test suite ... but when I double checked the code I found some sloppiness: it uses a couple of instance variables as a scratch pad while searching. This means that, under the right timing, even reads of the effectively immutable Map by different threads would interfere with each other, with Thread A getting the result from Thread B's query. Here's a diff of the solution, which basically moved those two scratch variables into their own inner class.

Things are working perfectly (for now), which is a great relief. This bug hunt was a distraction from other things, but better to tackle it now than later. This is also a good example of the need for a continuous integration server ... the fact that the server is on a different OS and JDK ensured that the tests would fail pretty consistently on the CI server even though they mostly worked on my Mac. Brian states this as well is his book ... test on all sorts of hardware with all sorts of memory configurations, because you don't know which one aligns with your bugs and brings them out into the open.

T5 Spring Integration -- Hibernate next?

I've put together a first pass at Tapestry 5/Spring integration as another new module: tapestry-spring-integration.

It's small and to the point, leveraging the normal Spring configuration for web applications, just making beans available for injection into Tapestry components and services. Also, it makes accessing the Spring beans (from the Tapestry side) case insensitive.

Next up will be some form of Tapestry 5 / Hibernate integration ... however, due to the conflicting licenses, I may take a pass at tapestry-ejb3.

That licensing is driving me crazy; I've checked repeatedly with the Lords of Apache Licensing, and they maintain that the ASL is not compatible with the LGPL, that by linking to LGPL code (importing LGPL classes, in Java terms) the LGPL "infects" the ASL code, adding an unwanted restriction not present in ASL.

From the sidelines, it's funny and disturbing: The ASL folks talk about "fauxpen source licenses" as if openness was purely black and white, and the least restriction was a total betrayal. Meanwhile, the FSF camp keeps saying the licenses are compatible. Go figure.

I've had discussions with people who really got heated over ASL vs. LGPL. Andrew Oliver, for one, really tried to sell me on the idea that the ASL was a boon for corporations over individuals. From my position, the theoretical taking of "Tapestry" over by, say, IBM and rebranding it as "IBM Web Presentation Objects" (or something) would be laughable ... and even if it did happen, I think it would still be good for Tapestry, which is good for me, and good for the Tapestry community. True open source forks are really rare and look more like a straw man argument than a real consideration.

Screencast #5: Grid Component

The latest Tapestry 5 Screencast is now ready; this one clocks in at almost 11 minutes, and shows me forgetting parameter names and such as I set up a grid with my good ole' fallback: iTunes music data. I actually made a couple of mistakes on purpose to show off the exception reporting (that's only gotten better since 5.0.2, the base line for this screencast).

I think this shows off how quickly and easily you can pull data out of a service and up on the screen. To borrow a phrase: "I don't have time for drag and drop!"

One minor mistake was that I didn't map the context correctly (I had cut-n-pasted an existing launch configuration); thus all the URLs are prefixed with "hilo/" rather than, say, "musiclib/". Oh well. Oops, and I forgot to hide the dock!

Maven Archetype for Tapestry 4

Sure, Webtide did it first, but it seems like Josh Long may have done it better: Tapestry 4 Maven Archetype.

Tapestry 5.0.2 released

A new preview release, Tapestry 5.0.2 is now available. It fixes a number of bugs and adds a number of features (including line precise exception reporting, and sortable Grid columns). Along the way, I found out some important deployment notes about Tomcat (and JBoss).

The new release is available via the central Maven repository, or via direct download.

Tapestry 5 and Groovy

I was curious just how well T5 and Groovy would work together, so I took an existing application, enabled Groovy for it (using the Eclipse plugin) and added a Groove page to my existing application:

package org.example.hilo.pages;

class Holder
{
  String firstName;
  String lastName;
  int age;
}

class Groove {

 def message()
 {
   "Get your Groove on, Baby!"
 }
 
 def onAction()
 {
  println "onAction invoked"
 }
 
 def items()
 {
   [ new Holder(firstName: "Howard", lastName:"Lewis Ship", age:40), new Holder(firstName: "Scott", lastName: "Simon", age:42) ]
 }
}

Guess what? It just worked, no problems. I generated a Grid with the two Holder items, my onAction() method is invocable, and I can retrieve the message. It is just bytecode under the covers.

Alas, without some kind of annotation support, there's no way to mark a field as persistent, so there's tremendous limits on what can be accomplished right now. I've heard rumors that some kind of JDK annotation support is forthcoming; failing that, I've thought about an additional file, read at runtime, that would provide class, method and field annotations. But I'd rather someone else does it.

In addition, Tapestry is reading the compiled .class file; I haven't even thought about trying to get things to work from uncompiled .groovy files and I can imagine there may be some class loader headaches there.

Still, for five minutes effort, it was nice. And I really think I could come to really like the streamlined, sensible syntax ... and for god's sake, first class closures!

Updated Tapestry Tutorial

I've updated the Tapestry 5 Tutorial, adding chapter 3, which is about the basics (including ActionLink). I may need to trim down some of the theoreticals, it's a bit verbose.

Tapestry 5.0.2 is ready to be announced on monday; one of the last things in was a renewed Exception Report page, including the return of line precise exception reporting. I've gotten better at design layout & CSS (though still pretty lame) but the results are looking good (you can seen a screenshot of the exception report page in the tutorial).

T5 coming together rapidly

A long day today, fixing bugs, adding missing features, and otherwise getting things ready for another preview release, 5.0.2. I just re-implemented the support for line precise exception reporting (the part that shows the content of the file in error) and, with a bunch of new CSS tricks up my sleeve, it looks better than ever. At least, on Firefox it does. Somehow I'm sure the ExceptionReport page will pop up when I do the next screencast.

I also added a lot of documentation on page navigation in Tapestry 5, finally documenting exactly what event handler method return values are meaningful, and what behavior they trigger. Of course, that's extensible via service configuration contributions.

I've got many more things on my plate: there seems to be an issue with localization, at least according to one Chinese (or at least, Asian) user. I need to get cracking on nicely integrated JavaScript. I need to support dates with a date translator and some date validators. Lots of stuff related to Ajax, especially the intersection of Ajax and form support. Well, just plain lots and lots more. Joy.

See you at JavaOne!

My Birds of a Feather session, "Tapestry 5: Java Programming Language Power, Scripting Ease" is in for JavaOne. No details on when and where (I predict someplace dank and dark, and late at night when all the good parties are going) but still, it's good to get the nod this year, given how competitive it is.

I promised Ajax features and live demos; I haven't written the Ajax stuff yet, but the live demos will be cake with Tapestry 5.

Hope to see everyone there!

Fighting with Tomcat

It all started innocently enough, TAPESTRY-1287: Tapestry does not deploy properly under JBoss 4.0. Just a simple security or configuration problem, no biggie I thought.

Turns out, its not JBoss at all, it's Tomcat 5.5.20.

Tapestry 5 relies on a feature of class loaders: If you invoke ClassLoader.getResources() with a folder path, it returns the URLs of the folders. Sometimes this URL is for a file on the filesystem, and if you open the connection you get a series of lines identifying the files and sub-folders. Other times, the URL is for a JAR and you get a JARURLConnection and ultimately a JarFile instance.

Tapestry uses this information to scan the classpath, including the WAR, for all page and component classes. This is the key part of the case insensitivity feature.

This works great under Jetty and I didn't give it a second thought until this bug popped up.

Alas, Tomcat works very differently. It partially explodes the WAR on deployment, but doesn't extract the classes to WEB-INF/classes. It also doesn't do what Jetty and the JVM's ClassLoaders do, in terms of responding sensibly to folder paths (as discussed above).

That leaves Tapestry 5 out in the cold, because it can't locate any of the web application's pages, either via the supported approach, ServletContext.getResourcePaths(), or via the ClassLoader approach (which is not documented but completely reasonable).

Tapestry isn't the first one to hit the kind of problem; a recent JBoss bug, JBAS-2676 shows that the Facelets crew hit a similar problem, and I've added Bug 41664 to ASF's Bugzilla to see if I can get a response.

So, I'm starting to dig around, to see if there's any magic I can use to kludge together a workaround. I've been hunting around in the debugger, trying to find some object that has a reference to the original WAR, which I could open up and read, just to scan WEB-INF/classes.

If that doesn't come together soon, I'll need a different approach, such as a Maven task to locate the classes and add some kind of index file to the WAR that can be used at runtime. I've really been trying to avoid doing anything that requires anything special during build and deploy, I want everything to just work ... and Tomcat is letting me down!

Blog comments disabled temporarily

I've had to cancel blog comments for a little bit, until the current wave of comment spammers "play through".

T5: Component Reference Documentation

Had a frustrating weekend struggling with Maven (those people are sadists) and with Javadoc (just plain idiots), but the end result is a Maven report plugin to generate component reference documentation.

Here's a sample, for tapestry-core.

Now, this is just the reference documentation, equivalent to JavaDoc: a starting point for real documentation. But it is generated right off the source files (via a JavaDoc doclet) so it is always automatically up to date.

T5 Screencast #4: BeanEditForm

Just finished a new screencast on BeanEditForm: Tapestry 5 Screencast #4.

In twelve minutes (including some lovely fumbling around the 8 minute mark), I only scratch the surface of what BeanEditForm can do, and it's still not quite as powerful as Daniel Gredler's BeanForm component for Tapestry 4 ... but it is easy and fast and full of fun tricks.

Introducing this component first, and only incidentally talking about Label and TextField, is according to plan. I want people to get hooked on Tapestry 5's power and ease of use immediately.

Next up: the Grid component.

Direct Component Rendering in T5

One question that pops up in the T4 mailing lists quite often is "How do I render a PDF?" (or a chart, or an Excel spreadsheet, etc.).

In T4, this takes a bit of care and planning: a new engine service to represent the resource to be generated, perhaps a new Asset implementation that references the service. The necessary HiveMind configuration to add the engine service to the mix, and perhaps give it a friendly URL mapping. Perhaps a touch of web.xml for that last bit as well.

In Tapestry 5, there's an interface, StreamResponse, that may be used as the return value from an component event handler method. StreamResponse encapsulates a MIME content type, and an InputStream that will be read and pumped down to the client.

And that's really all it takes. Here's an example from the test suite:

public class Start
{
    Object onActionFromTextStreamResponse()
    {
        String text = "<html><body>Success!</body></html>";

        return new TextStreamResponse("text/html", text);
    }
}

This method is invoked when the corresponding component's link is clicked; from the template:

<a t:type="ActionLink" t:id="textStreamResponse">Text Stream Response</a>

This is just an event handler method; normally these return a page name or a page instance, and a client redirect is sent to get that page to render. By returning a StreamResponse, it is the stream response that is returned to the client (immediately, in the same request; there's no redirect).

That's the point of T5: Simple things should be easy.

More Tapestry 5: Grid Component, Case Insensitivity

I've been busy building a Grid component to replace T4's contrib:Table component. It's coming out great, I can't wait to put up a screen cast of it soon (once I get sorting working). It has a clean UI (more default CSS), uses a Digg-style pager, at the bottom, and it's scary fast.

Better yet, its pretty automatic. If you pass the Grid a list of components, it builds its model from the first component (it expects them to be uniform). The model even understands the order of properties, based on the order of the getter methods within the bean class. It uses similar concepts to the BeanEditor to create default labels and so forth. Basically, it's zero configuration ... push a list of objects at it, and it will build the entire UI, column labels, column order ... the whole enchilada.

Meanwhile, I've been working under the covers to further extend the bounds of case insensitivity. It's now a hard-wired concept inside Tapestry IOC, which provides a CaseInsensitiveMap (a full java.util.Map where the keys are case insensitive) to properly support it. I'll be able to strip out a whole lot of string.toLowerCase() calls inside tapestry-core (I'm just taking a little break now). Back to the point ... now when you are injecting, contributing, or doing anything else with Tapestry IOC the case of the ids just don't matter anymore. One less thing to worry about while developing (no more "is that 'Checkbox' or 'CheckBox'?").

I showed off some Tapestry 5 to my friends at Formos and they loved every bit of it. Here's a company that develops exclusively in Tapestry, and has concurrent projects in Tapestry 3 and Tapestry 4 and they loved every bit of it. Many of my "innovations" were similar to things they extended Tapestry to do for their applications, but they appreciated the idea that it is baked into Tapestry itself. And there's a few other ideas I've had that haven't occured to anyone else yet.

It was very gratifying to see how excited they got by Tapestry IOC. "It's HiveMind -- without the XML, come check it out!". So it's nice to get a little confirmation that things are on the right track.

Mac/PC Parody Ads

Tip of the hat to Ted Neward for pointing these out: Parodies of the "I'm a Mac/I'm a PC" ads.

New Screencast: Tapestry Maven Archetype

I've added a new screencast, this one showing off the use of the tapestry-simple Maven archetype to create a new project. It runs about five minutes and shows off how simple it is to get up and running.

If you haven't built Tapestry 5 locally, you need to remember to add -DremoteRepositories=http://people.apache.org/repo/m2-snapshot-repository/ to the command line.

I'm thinking about starting a vote to do a preview release of Tapestry 5, just to get the necessary JARs and archetypes into the general Maven repository.

Tapestry 5: Caseless URLs

Big improvements to Tapestry 5 URLs today. Whereas Tapestry 4 had "friendly URLs" (friendly to what? Mostly to search engines), Tapestry 5 has "pretty URLs" that look much more like their hand-tooled brethrern.

The news today is that the pretty URLs are now case-insensitive. Well, that's a slight exaggeration; the portion of the URL that specifies the name of the page and the component id within the page is now case insensitive. Thus http://localhost:8080/login.form.action is exactly the same, to Tapestry, as http://localhost:8080/LOGIN.FORM.ACTION¹. The first form, all lower case, is what's generated by Tapestry by default.

Under Tapestry 5, there are really two main types of URLs: component event URLs and page render URLs. Page render URLs are now just the name of the page, i.e., http://localhost:8080/login ... there's no longer an extension tacked on. Submitting forms, or clicking component action links, does some processing and sends back a page render URL, so what you see in the browser's address bar is always a bookmarkable, short, relatively opaque URL.

In some cases, a page will have a "passified context" which is just a very generic way of saying, "the primary key for the entity this page displays". Thus you might have a ViewPerson page that uses some kind of numeric id as its context. The URL ends up being http://localhost:8080/viewperson/99. In other words, the URLs Tapestry is generating end up looking pretty much exactly like what you'd create in a hand-tooled application. And all of this with zero configuration. It just works.

¹As I typed this, I realized that the last part of the URL, ".action", which is the component event name, is not currently case insensitive, something I'll address tormorrow.

Tapestry 5 Maven Archetype

I've just put together a rather decent Maven Archetype for Tapestry 5. It's called "tapestry-simple" and its documented here.

The archetype allows you to create a Tapestry 5 application in, literally, seconds. It generates the pom.xml (for Maven), .classpath/.project (for Eclipse), as well as web.xml, log4j.properties, the complete directory structure, even a sample Start.html and Start.java.

It also configures the Jetty plugin so that you can immediately run the application using "mvn jetty:run".

This took only a little doing. The Maven documentation was awful as usual (yes, kettle, stove, etc.), but peeking at a couple of the sample archetypes, and trying some experiments, allowed me to put together something relatively complete and polished in a couple of hours. And those hours will save thousands of developers an hour or two each.

To make this work, you need to edit your settings.xml to add in the Apache snapshot repository at http://people.apache.org/repo/m2-snapshot-repository/ ... but perhaps better (and almost as easy) is to check out the latest Tapestry 5 source from SVN and build locally. You'll want the tapestry-project, tapestry-ioc, tapestry-core and tapestry-simple projects. Do a "mvn clean install" and all the latest and greatest will be in your local Maven repository!

1.0.0 releases for tapestry-prop, -flash, -spring

I've gotten no negative feedback on the main three libraries at Tapestry @ JavaForge so it's time for a 1.0.0 release for all three:

• tapestry-spring - Tapestry/Spring integration
• tapestry-prop - Highly efficient property access, used instead of OGNL in many palces
• tapestry-flash - Temporary storage of data until the next request (often used for redirect-after-post messages)

The files are all available from my Maven 2 repository: http://howardlewisship.com/repository/. If you aren't a Maven user, the binary and source distribution are available at http://howardlewisship.com/downloads/tapestry-javaforge/.

Note that all of these are compiled against Tapestry 4.0.2, the latest stable release of Tapestry. Once Tapestry 4.1 has a stable release, I'll bump the version numbers and update the dependency.

Proposal for new property operator

There's been a few blog postings about adding property support to the Java language properly. Here's a synopsis. The goal is to make it easier to access object properties, using property names, rather than method names.

I'm amazed at some people's ability to Not Get It.

The proposal is too add a special operator, ->, for this purpose.

This means that you have to be aware that something is a property before you know how to access it.

Properties in other languages are powerful because they are accessed just like fields. You see this in Ruby especially. You can change your mind and switch from simple public instance variables to getter/setter methods at any time, without breaking any existing code. Ruby will even generate the getter and setter for you. Braindead simple.

So, Mr. Danny Coward, here's a proposal for you. I would like the property access operator to be ..

Let me make that more clear: .

You know, the exact operator used in other languages, the exact operator that anyone would expect.

Let the compiler do the work. The -> operator is an approach to make the compiler do less work and the developer do more. That is ass-backwards. I'm slaying dragons over here in Tapestry 5 land, to make the environment bend over backwards to adapt to the user, easily and seamlessly. It would be nice if the overlords in charge of the Java language would take that as their lesson. Complexity is not solved by adding more complexity. Complexity is solved by removing complexity ... even if it requires a bit more work behind the scenes to support that simplicity.

Of course, this may all be a distraction from their main attemmpt to screw the pooch: super modules. More on that soon.

Latest T5 Snapshots: Invisible Instrumentation

I just uploaded the latest T5 snapshots. I did some work on the template parser; you now have an alternate template syntax, more like Tapestry 4:

<span t:id="foo" t:type="Bar" param="literal-string"/>

In Tapestry 4, it would be the same, except jwcid="foo@Bar".

I'm struggling with what's the correct binding prefix? With <t:comp> the default binding prefix is "prop:", meaning a property name or property path unless an explicit prefix is given.

With invisibly instrumented elements, the expectation is that more of the parameters will be fixed string literals, so the default binding prefix is "literal:". Thus you might have to do the following:

<input type="text" t:id="userName" t:type="TextField" value="prop:userName" validate="validate:required"/>

However, there's some implemented and upcoming improvements that will shorten and simplify this snippet.

Notice that the t:id and value attributes are pretty much the same? That's a Dont Repeat Yourself violation; Tapestry 5 already handles this particular case: if the value parameter is omitted, it is assumed to match a property of the container with same name as the component's id. This is already implemented. So the example is reduced to:

<input type="text" t:id="userName" t:type="TextField" validate="validate:required"/>

The remaining ideas are not yet implemented.

We've put <input type="text"> into the template for preview purposes. Tapestry should be able to deduce that we want a TextField component. That reduces the example to:

<input type="text" t:id="userName" validate="validate:required"/>

The final change refers to the validate parameter. It's type is FieldValidator, not string ... that's why we're invoking the "validate:" binding factory to convert the string ("required") into a FieldVaidator instance. I'm not sure what this would look like (either special code on the TextField component, or some additional logic to invoke the ValidateBindingFactory), but it seems to me we should be able to remove the "validate:" portion:

<input type="text" t:id="userName" validate="required"/>

This is part of the goal of Tapestry, that whether you're writing templates or Java code, you should only write the bare minimum that's necessary, and Tapestry should be able to fill in the gaps. That's partly convention over configuration, but the overall concept goes deeper than that.

This last bit, omitting the need for explicit binding prefixes, was a battle I lost in the Tapestry 4 time frame, but the approach I was taking then was more involved; a default binding prefix for each parameter. I just want Tapestry to realize that I supplied a simple string, but the component needs a FieldValidator, and that those come from athe ValidatorBindingFactory service. Tapestry should be able to close the loop on that without generating any surprises.

HiveDoc for Maven 2

Marcus Schulte has put together a Maven 2 plugin for HiveDoc. It generates very good hypertext documentation, with a better layout than than the built-in documentation and well integrated into the overall Maven site. An example of the generated documentation comes from the honeycomb project (which is one of the Hibernate integration modules available for HiveMind and Tapestry). Happy New Year, Marcus ... and thanks!

Waiting for VMWare Mac

I'm looking forward to doing more Tapestry 4 training fairly soon, and some Tapestry 5 training in the medium future. One important part of my arsenal is missing: VMWare for Mac. Four months ago they said "open beta real soon now" (i.e., by the end of the year). I hope I don't have to lug along my old Dell Laptop, just to run my VMWare Ubuntu image!

Tapestry 101

Warner Onstine's book on Tapestry 4: Tapestry 101 is now available!

Tapestry 101 is a great introduction to Tapestry using real-world examples. It goes beyond just using Tapestry components and dives into integrating Tapestry with Spring and with Hibernate. It's organized around a real application implemented in the small and should go a great way towards filling in the gaps in people's Tapestry knowlege.

It's available right now as a downloadable PDF.

The Difference between Blogs and Support Lines

The difference between Blogs and Support Lines:

Tapestry questions posted as blog comments don't get answered.

If you have a question about Tapestry, the tapestry user mailing list (users@tapestry.apache.org) is the correct starting point. Questions asked there get answered pretty quickly, by the Tapestry community (including the committers).

Failing that, you can contact me or any of the other Tapestry committers. Just remember that for us, Tapestry is a business and answering questions can be a distraction, a drain on resources that needs compensation.

From my perspective, every minute of my time should be spent on Tapestry 5. Any distraction from that, any time I could be working on T5 but end up working on something else, is a net negative for the Tapestry community as a whole.

So if you're one of the folks whose been posting various questions onto the blog as comments (I see all the comments because I moderate them) ... well, now you know why I don't usually answer. This simply isn't the right venue or the right situation.

Tapestry 5 Progress: Localization, Assets

Been rapidly reassembling Tapestry functionality inside the new Tapestry 5 code base.

A first pass at localization is now in place. It's missing a couple of key features and a bunch of bells and whistles, but the basics are in place.

I've also started implementing assets. Currently, only context assets are supported, but I'll be working on classpath assets next.

Both of these things were necessary detours before I could start work on form input validation in earnest.

The code is coming together rapidly and very nicely, very cleanly.

I've been stretching to meet "the principle of least surprise" ... just looking for ways that the framework can cleanly and easily do things automatically. For example, the @Inject annotation is very flexible; it takes into account the type of field when determining how to interpret its value. @InjectAsset would have been easier, but that's one more thing for people to remember.

Also, I'm working on an "automatic" Tapestry stylesheet. I want Tapestry apps to have a good, clean look automatically, by inheriting a base stylesheet from the application itself.

Interestingly, because of the way Tapestry 5 renders (to a simplified DOM), it won't be necessary to have Shell or Body components, as with Tapestry 4. There's a post-processing stage that will be able to navigate the DOM and make selected changes, somewhat like a limited version of SiteMesh. This stage will be able to do things like insert a stylesheet link into the <head>.

In fact, I think there will be significantly fewer components in Tapestry 5, especially because of mixins (which will allow existing components to be used in new ways, rather than forcing the creation of entirely new components).

Onward and upwards. Less is More

Firefox 2.0 stability on Mac OS X

I've found that Firefox 2.0 is simply not stable on Mac OS X (10.4.8 Intel). It was locking up on my multiple times a day. I downgraded to 1.5 and have had virtually no problems since (in the last couple of weeks).

It seemed like it had trouble with heavy JavaScript pages such as Google Mail. Again, 1.5 is fine.

It really is like being between a rock and a hard place; Safari is faster and more stable but doesn't do everything I want it to do (such as the WebDeveloper or FireBug plugins to Firefox). FireFox is less "OS-X-y" (James Duncan Davidson won't run it because it feels like a Windows program to him ... and it sure could use a few more glowing curvy glass buttons!). Some common JavaScript, such as animation effects from Dojo, run incorrectly in Safari but correctly in FireFox. So, what's next ... Opera?

Nope, probably stay with Firefox (1.5, until they admit there are Mac OS X problems and fix them). It's much more likely that my clients will be running FireFox than Safari or Opera (my clients, and my client's client's are almost universally running Windows). I think a shift has occured, where people understand that Firefox is the standard, and that IE may take some extra effort "to get working correctly". I'm not saying people don't expect things to run flawlessly in IE ... just that they understand that it's not automatic, that IE makes things harder.

The Danger of Beta: Tapestry and HiveMind Blog has Moved

Some day there will be a medical diagnosis for my condition, which may be characterized as an overeagerness to adopt unstable beta software.

In this case, it was a switch to Blogger Beta, which promised all kinds of improvements to the user experience of reading this blog. Alas, the real improvements are of questionable value, such as publishing an Atom feed where the RSS feed used to be (and not writing the correct <link> tags).

Anyway, it became pretty evident that the new, post Google Blogger really wants to host the blog on blogspot.com. Thus the new URL:

http://tapestryjava.blogspot.com

Updates to Tapestry @ JavaForge

Well, I've had a busy morning. I've done a ton of work on the projects at Tapestry @ JavaForge.

I've changed the version number of everything to 1.0.0-SNAPSHOT.

Documentation has been updated. Site navigation updated. Look and feel is now aligned with everything else Tapestry.

This was spurred by a comment in the user mailing list about how tapestry-spring doesn't work with prototype beans. It does, but I haven't updated the documentation.

Of course, Maven 2 is letting me down here. It doesn't support site publishing via FTP (just secure FTP and various SSH related options). This adds a manual step to deploying the documentation that I'll roll into a Ruby script next time I publish.

Anyway, tapestry-testng, tapestry-flash and tapestry-spring are release candidates. tapestry-prop may have a few features (already in Tapestry 5) added to it before its final.

Switched!

I've joined the legions of other No Fluff Just Stuff speakers, excluding (of course), Ted Neward, who are running on Mac. A MacBook Pro (the latest version) with 2 gig of ram, and a 30" cinema display.

Of course, the user experience is fantastic, especially with the 30" display. I don't even own a TV that large. It's so big that I sometimes have to pull windows with small text down to eye level for easy reading. Scary big. Ridiculously big. Love it.

In one respect, it's like coming back home; my first real windowing environment (the first I developed applications for) was NeXTSTEP back in the mid 90's. I developed a big database driven GUI app using AppKit and Enterprise Objects Framework. I remember an Apple rep coming by to show us some weird thing called WebObjects, but that's a different story.

It's intimidating ... there's so much new stuff to learn. Hanging around with Stu, Justin, Neal and Dave (among many others) who are so big on mastering your environment and working smart ... well, between Automator, Quicksilver, and everything else ... well, there's a lot to learn, a lot of catching up to do. And of course, Ruby is pre-installed as well.

Dashboard widgets look cool; as I'm trying to flex some JavaScript muscle, that's a definite way to build something useful as well.

So far, the only thing I don't like is the Mighty Mouse; I already ditched mine on Ebay and am using the same Logitech LX7 I use on my Aurora (windows desktop). I also had to pick up a keyboard, since the monitor is so huge I can't get the laptop (and it's keyboard) anywhere near it.

Also, OS X doesn't give you the choice about what to do with your laptop monitor when plugged into an external display. I'd just as soon shut it off but no ... it has to be a desktop extension. Once I get a little more settled in, I'll need to pick up one of those "Hacks" books.

So, exciting and scary. I have so many things to learn.

Improve Tapestry performance with tapestry-prop

I've just deployed a new version of the tapestry-prop library for Tapestry 4.0. tapestry-prop adds a new binding prefix, "prop:", as an alternative to "ognl:". The actual moving of property values is accomplished using runtime generated bytecode, which performs better than OGNL's use of reflection.

The major new feature is support for property paths. You may now uses a series of property names, i.e., user.name. This vastly extends the usefulness of the "prop:" binding, since is can be used in about 90% of the places you'd normally use "ognl:".

The lack of reflection means that "prop:" peforms almost exactly the same as pure Java code. Based on some cursory performance testing, we're looking at a 27x improvement. In a typical Tapestry page, I suspect this may add up to a millisecond or so per request.

The version number has been changed to 1.0.0-snapshot. tapestry-prop should work with JDK 1.3 (Tapestry's minimum requirement).

If you were paying attention during the screencast, you'll note that an even more powerful version of this code is the default binding prefix in Tapestry 5.

Tapestry -- Duke's Choice Photos

Duke's Choice Lineup, originally uploaded by Tapestry Dude.

Finally got around to uploading some shots taken at JavaOne 2006. Here's a slideshow from the Duke's Choice award ceremony.

A step back from the bleeding edge

In an earlier post, I blogged about my gamble with using AspectJ. Well, I've been having Eclipse performance and stability problems for a while now, as I've upgraded Eclipse from 3.1.x to 3.2 to 3.2.1 and kept updating my AspectJ plugins. I've had issues with Maven and AspectJ, especially with Corbetura and AspectJ.

For what? Some clever defensive programming ideas (automatic null checking of parameters), a little bit of concurrency help, and a few additional cases.

Much as I liked the automatic null checking, I found increasingly that I was supressing it (with a special annotation) in many cases. In fact, the most useful place for such checking is in bridge code between user application code and the public Tapestry API ... and that's really not a lot of code.

The concurrency support was nice, but expensive. I found that in most cases I could convert to using copy-on-write, threadsafe collections instead. For the couple of cases where I couldn't I put together a utility class to manage the reentrant read/write lock on behalf of other code.

So ... goodbye AspectJ (for the meantime). Positive improvements: shrunk the size of the JAR by about 30% (657K down to 449K), plus no runtime dependency on AspectJ. Everything's running great. No problems.

Dissapointing. AspectJ still has a raft of very important uses, but the cost (in terms of developer frustrations) outweighs the benefits, at least for nice clean, new code like the Tapestry 5 code base.

Tapestry 5 Screencast #2

This one shows how to use built-in Tapestry components, touches on the exception page, transient and persistent properties, and component event handler methods. Along the way, we see just how great it is to be able to change code on the fly! Tapestry 5 Technology Preview #2 -- 20 Oct 2006

The screencast clocks in at about 9 minutes.

For Tapestry 4 users, the two big things to pay attention to:

• Action handler methods, not listener methods
• Action requests send a client refresh, not updated HTML

The latter one is a big change from Tapestry 4, and implies that more data will have to be persistent between requests; the good news is that client property persistence, as well as flash persistence, will be supported fairly soon.

The constant question is: When will it be done? We'll be getting to the point where the other Tapestry developers can join the fun pretty soon, once I get basic forms and input validation working. I can see a useful platform ready in the spring and a final release, with some form of Spring and Hibernate integration, in the summer. Of course, my schedule is anything but fixed and set (I do have to earn a living around all of this!).

By the way, these screencasts are all done in a single take. What you see, complete with me fumbling with System.out.println, was my third full run through.

Page response is really that fast, even in the face of code changes. I'm not editting out pauses or any tricks like that. It's not just fast due to my dual-core monster desktop either; I've seen just as nice results on my more puny laptop. It's going to be hard to work on any other platform where I actually have to restart or redeploy just to see changes to my code!

HiveMind now an Apache Top Level Project

Finally ... HiveMind is now a top level project at Apache. This is great news, because it will allow the team to bring in HiveMind extensions from all over and put them under one roof.

I've been neglecting HiveMind for a while now as I concentrate on Tapestry 5, which is a shame, but unavoidable. Certainly, the people working on it now are quite capable. In fact, as often as not, if you see a clever idea in HiveMind, it was suggested or even implemented by James or Knut or one of the others.

Tapestry 5 Screencast #1

I've just put together a 6 minute screencast about Tapestry 5. It covers creating a new project (using Maven), setting up dependencies and structure, and creating a page template and seeing changes to the live application when you change a Java class.

Tapestry 5 Technology Preview #1 -- 17 Oct 2006

Class reloading is a key feature of Tapestry 5 and is exceptionally important to the stellar productivity Tapestry 5 will enable. Just as people fastened on to the Tapestry 3/4 templating system, I think many people will fasten on to class reloading. Don't be mistaken; there's a lot more to this enchilada than that one feature. But it's a great feature to hook people early on!

The Ajax Experience -- Next Week

Just a reminder that The Ajax Experience is just over a week away.

Jesse Kuhnert and I will be presenting: Tapestry and Dojo: The Peanut Butter and Jelly of the Ajax World:

Dojo is an open source JavaScript library that provides an improved programming model for JavaScript and a suite of client-side tools and widges. Tapestry is an innovative open source client-side Java framework for building componentized web applications. At first glance, these two look like the Odd Couple, but pull back the covers a bit and you'll see a similar event model and design philosophy that makes these frameworks a cinch to put together. Tapestry 4.1 with Dojo brings about client-side Ajax joy without server-side Java pain.

I just got back from ApacheCon 2006, which was a fun time. I got a chance to talk Tapestry with members of the Shale team and with a few Tapestry users; I even demoed some of the new Tapestry 5 features (resulting in a few dropped jaws). Catch me at The Ajax Experience for more of the same! I also got a bunch of speakers hooked on the Hive boardgame.

It's interesting that one of Tapestry's core concepts, that the controller and view are tightly bound together, is a stumbling block for the Struts/Shale folks. They've been forced to deal with this outlandish, awkward, counter-productive separation between their business logic and their presentation/output for so long you can just see the gears gnashing together when thinking of something else, something that doesn't require tons of tedious coding and configuration. I'm in the process of adding some "Tapestry for Struts Programmers" documentation to the Tapestry 5 site, to try and outline the issues with action frameworks, and the solutions Tapestry offers.

Tapestry: A Component-Centric Framework

While I was on the road last week, I never had a chance to blog about a new article on OnJava: Tapestry: A Component-Centric Framework.

As usual, there are a number of things that rub me the wrong way. For example, I never use the class attribute of the page or component specification, I configure Tapestry to find my pages and my classes in appropriate packages.

The formatting of the examples in the article is a bit odd. I'm not sure who this article serves ... the article claims to show "how simple it is to develop a web application in Tapestry" but it doesn't come close. Actually, if I didn't know Tapestry not only would I not be interested in pursuing it because of this article, I would almost certainly be persuaded not to research further.

Nice to see more Tapestry in print, but as they say, if you want something done right ...

You'll be much better of reading Warner Onstine's Tapestry 101 once that's available. I've been doing the technical edits of this book as each chapter is ready and it's much closer to the mark!

eZing Builder -- WYSIWYG Builder for Tapestry

It's very unfortunate that Spindle has stalled, short of adding Tapestry 4 support. Fortunately, it's a big world and others have started stepping in to fill the gaps. On approach is Cognition, which uses a visual builder tied to a data model driven architecture.

Another one just brought to my attention is eZing Builder. From what I can tell (the site's a little short on documentation, and SourceForge is currently down for maintenance), it's a general purpose WYSIWYG editor for web applications, with specific Tapestry extensions. Built on Eclipse 3.2, and open source. Looks nice.

Very handy Regular Expression Tool: QuickREx

I was puzzling out how to do some text processing in Tapestry and it came down to some regular expressions. Now, I use these all the time, but I'm not hyper literate in them ... I always need to test them out before I feel confident in them. I had been using an Eclipse plugin for this that went payware, so for I while I was firing up IRB (interactive Ruby).

Fortunately, during a quick thinking break, I decided to see if there was a new Eclipse tool for this ... and there is QuickREx.

It does a very good job ... it allows you to write your regular expression, provide it with sample text, and view matches and groups within matches very nicely. You can set options (such as multiline or caseless) and it even can run for all the major different RE implementations out there (JDK, ORO Perl, ORO Awk, and JRegex). It does live evaluation, which really helps when trying to "tweak" the expression, and has a bunch of other well thought out features, such as helping you to paste the final expression into Java code (escaping the backslashes, and such, for you).

The expression editor includes completion; hitting ctrl-space brings up a menu of different regular expression codes to insert, each with a snippet of documentation. Nice.

The plugin also includes a secondary view, the Regular Expression Library. This contains a library of regular expressions, each with example text to match against and a chunk of documentation.

In fact, there's a few more features that are hard to explain out of context, but I suspect will prove quite useful. This is another example of a finely crafted tool created not as a demonstration of someone's Eclipse plugin coding chops, but created to be used.

Easy install via the update manager http://www.bastian-bergerhoff.com/eclipse/features) and it's run flawlessly since.

More Tapestry / Hibernate Integration: Honeycomb

Honeycomb is another integration between Tapestry and Hibernate. What's neat is that it supports Session Per Conversation (somewhat like Seam) and Session Per Request (much more common) right out of the box.

It even includes Maven archetypes to get the project set up quickly. Nice.

Once again, the power of HiveMind is evident here; just placing the Honeycomb JARs on the classpath mixes all the Honeycomb support directly into the application. No additional configuration needed.

On the other hand, there's virtually no documentation on how to use Honeycomb beyond the Javadoc ... and some of that is in German!

Javassist vs. Every Other Bytecode Library Out There

I've been getting a small amount of flack about Tapestry and HiveMind's use of Javassist. Yes, its inside the evil JBoss camp. Yes, it has a wierd MPL/LGPL dual license. Yes, the documentation is an abomination. Yes, the API is so ugly that I always craft an insulation layer on top of it. Yes, there are are other bytecode toolkits out there. So why am I so wedded to Javassist?

Because it's so damn powerful and expressive.

A lot of the magic in HiveMind and Tapestry 4 is due to Javassist, and Tapestry 5 is even more wedded to it.

Much of what HiveMind does could be done using JDK dynamic proxies. HiveMind uses proxies to defer creation of services until just needed ... you invoke a method on the proxy and it will go create the real object and re-invoke the method on that real service object. You code never has to worry about whether the service exists yet or not, it simply gets created as needed.

You can do things like that using JDK proxies, but proxies are not going to be as optimized by Hotspot as real Java classes. The core of dynamic proxies is to use reflection, each method invocation on the proxy turns into a reflective method invocation by the proxy's handler. There's further overhead creating an array of objects to store the parameters.

Simple proxies like that can certainly be written using other toolkits like ASM.

Because these proxies are so common in Tapestry 5, my insulation layer can build the whole proxy as a single call; the insulation layer translates this to Javassist API:

    public void proxyMethodsToDelegate(Class serviceInterface, String delegateExpression,
            String toString)
    {
        addInterface(serviceInterface);

        MethodIterator mi = new MethodIterator(serviceInterface);

        while (mi.hasNext())
        {
            MethodSignature sig = mi.next();

            String body = format("return ($r) %s.%s($$);", delegateExpression, sig.getName());

            addMethod(Modifier.PUBLIC, sig, body);
        }

        if (!mi.getToString())
            addToString(toString);
    }

Here, delegate expression is the name of the variable to read, or the name of the method to execute, that provides a proxy. The only real part of this code that is Javassist is that code snippet: return ($r) %s.%s($$);. The first %s is the delegate expression; the second is the name of the method. Thus this may be something like: return ($r) _delegate.performOperation($$); Javassist has a special cast, ($r) that says “cast to the method's return type, possibly void”. It will unwrap boxed values to primitives, as necessary. The $$ means “pass the list of parameters to the method”.

Thus we can see how quickly we can build up new methods that invoke corresponding methods on some other object.

In Tapestry 5, the real workhorse is the ClassTransformation system which is used, with Javassist, to transform classes as they are loaded into memory. This is how Tapestry 5 hooks into the fields of your class to perform injections and state management. Tapestry 4 did the same thing using abstract properties and a runtime concrete subclass … this is much more pleasant.

Some of the trickiest code relates to component parameters; there are runtime decisions to be made based on whether the parameter is or is not bound, and whether the component is or is not currently rendering, and whether caching is or is not enabled for the parameter. Here’s just part of that logic, as related to reading a parameter.

    private void addReaderMethod(String fieldName, String cachedFieldName,
            String invariantFieldName, boolean cache, String parameterName, String fieldType,
            String resourcesFieldName, ClassTransformation transformation)
    {
        BodyBuilder builder = new BodyBuilder();
        builder.begin();

        builder.addln(
                "if (%s || ! %s.isLoaded() || ! %<s.isBound(\"%s\")) return %s;",
                cachedFieldName,
                resourcesFieldName,
                parameterName,
                fieldName);

        String cast = TransformUtils.getWrapperTypeName(fieldType);

        builder.addln(
                "%s result = ($r) ((%s) %s.readParameter(\"%s\", $type));",
                fieldType,
                cast,
                resourcesFieldName,
                parameterName);

        builder.add("if (%s", invariantFieldName);

        if (cache)
            builder.add(" || %s.isRendering()", resourcesFieldName);

        builder.addln(")");
        builder.begin();
        builder.addln("%s = result;", fieldName);
        builder.addln("%s = true;", cachedFieldName);
        builder.end();

        builder.addln("return result;");
        builder.end();

        String methodName = transformation.newMemberName("_read_parameter_" + parameterName);

        MethodSignature signature = new MethodSignature(Modifier.PRIVATE, fieldType, methodName,
                null, null);

        transformation.addMethod(signature, builder.toString());

        transformation.replaceReadAccess(fieldName, methodName);
    }

That last line, "replaceReadAccess", is also key: it finds every place in the class where existing code read the field, and replaces it with an invocation of the method that contains all the parameter reading logic … a method that was just dynamically added to the class. A typical implementation of a parameter writer method might look like:

private int _$read_parameter_value()
{
  if (_$value_cached || ! _$resources.isLoaded() || ! _$resources.isBound("value")) return _value;
  int result = ($r) ((java.lang.Integer) _$resources.readParameter("value", $type));
  if (_$value_invariant || _$resources.isRendering())
  {
    _value = result;
    _$value_cached = true;
  }
  return result;
}

The point of these examples is this: we’re doing some complex code creation and transformation and Javassist makes it easy to build up that logic by assembling Java-like scripting code. I’m not sure what the equivalents code transformations would look like in, say, ASM but I can’t see it being as straightforward and easy to debug. Javassist lets me focus on Tapestry and not on bytecode and that makes it invaluable.

Type Coercion in Tapestry 5

I just finished a bit of work I'm very proud of ... a fairly comprehensive type coercion framework for Tapestry 5.

Here's the problem: with the way you bind parameters in Tapestry, you are often supplying a value in one format (say, a String) when the type of the parameter (defined by the variable to which the @Parameter annotation is attached) is of another type, say int.

So ... who'se reponsible for converting that String into an Integer? Tapestry. Get used to that answer, because that's a big theme in Tapestry 5.

At the core of the solution is a simple interface for performing type coercions:

public interface Coercion<S, T>
{
    T coerce(S input);
}

Gussied up inside all that generics goodness is the idea that an object gets passed in, and some operation takes place that returns an object of a different type. Perhaps the input is a String and the output is a Double.

Now, we dress that up with a wrapper that helps Tapestry determine what the Coercion converts from (source/input) and to (target/output):

public class CoercionTuple<S, T>
{
    public CoercionTuple(Class<S> sourceType, Class<T> targetType, Coercion<S, T> coercer)
    {
      . . .
    }

    public Coercion<S, T> getCoercion() . . .

    public Class<S> getSourceType() . . .

    public Class<T> getTargetType() . . .
}

My brief look at Haskell influenced the naming ("tuple") and a lot of the overall design.

Now we have a service, TypeCoercer, that can perform the conversions:

public interface TypeCoercer
{
    <S, T> T coerce(S input, Class<T> targetType);
}

The TypeCoercer is seeded with a number of common coercion tuples (thanks to Tapestry IoC, you can contribute in more if you need to). From these tuples, the service can locate the correct coercion.

Now the neat part is that if there isn't an exact match for a coercion, that's not a problem. The service will search the tuple space and build a new coercion by combining the existing ones.

For example, there's a builtin String to Double tuple, and a builtin Number to Long tuple. The TypeCoercer will see that there's no way to convert String (or any of its super classes or extended interfaces) directly to an Integer, so it will start searching among the tuples that do apply.

This all happens automatically. Say you pass in a StringBuffer instead of a String; TypeCoercer will construct the compound coercion Object to String, String to Long, Long to Integer.

Writing this code was very pleasurable; too often the things I work on are too simple: move datum A to slot B, and I get the whole design for such a piece of code all at once and its just a scramble to get it coded (and tested, and documented) before that mental image fades. This time I had to work hard (despite the very small amount of code involved) to really understand the problem space and the algorithm to make it all work ... then back it up with a good number of tests.

Speaking at PJUG Sept. 26

I'll be doing a fast paced talk on Tapestry 4 at this month's Portland Java User's Group. This will be Tuesday, Sept. 26th at the Adtech II building in Northwest Portland. [map]

The meeting starts at 6:30pm.

Upgrading from Eclipse 3.1 to 3.2

I've been using an ever larger number of Eclipse plugins in my development. I'm using Jetty Launcher, Maven, AJDT (AspectJ), Oxygen (XML editor), Subclipse (SVN support), TestNG, and a few lesser ones.

Eclipse is pretty good about backwards compatibility, so I've tried just switching my eclipse folder from 3.1 to 3.2. Should be new JARs against my existing workspace and we're off and running.

No such luck. I was working on that yesterday and I quickly got to a point where I could not convince Eclipse 3.2 to even try and compile my code. It's on the class path, I can see the class files in the package explorer, but no dice on compiling.

My sneaking suspicion is that it's the Maven 0.0.9 plugin (this plugin keeps Eclipse dynamically up to date with your project's pom.xml).

So I downgraded to Eclipse 3.1. Guess what? No dice there either.

As you might imagine, this put me in a bit of a panic. I tried deleting my project and checking it back out of the repository. Still no dice. The panic level increased again.

My final solution was drastic: delete my workspace entirely. Eclipse stores considerable meta data about your project outside the folder itself. In the shuffling up to 3.2 and back to 3.1, some amount of that has been corrupted.

It's not so bad ... it's now spring cleaning time as I'm starting from an entirely fresh Eclipse install and even re-downloading just the essential plugins that I need.

Tapestry at The Ajax Experience

Jesse Kuhnert and I will be presenting at The Ajax Experience this year on Tapestry and Dojo.

Dojo is an open source JavaScript library that provides an improved programming model for JavaScript and a suite of client-side tools and widges. Tapestry is an innovative open source client-side Java framework for building componentized web applications. At first glance, these two look like the Odd Couple, but pull back the covers a bit and you'll see a similar event model and design philosophy that makes these frameworks a cinch to put together. Tapestry 4.1 with Dojo brings about client-side Ajax joy without server-side Java pain.

BeanForm Component

One of the compelling features in Rails is the ease with which forms for creating/editting/updating/deleteting objects can be created. Tapestry has a lot of power under the hood with respect to forms, but it still doesn't come cheap enough out of the box. A centerpiece of Trails is a component that builds a full form for editting an arbitrary object. This idea has resurfaced as a new standalone component, BeanForm.

Just plug the following into your page's HTML template:

<span jwcid="@bf:BeanForm" bean="ognl:pojo" save="listener:save" delete="listener:delete"/>

BeanForm will build a complete form from this, adapting to each individual property's type. If you are using EJB3 or Hibernate annotations, BeanForm will pick up those annotations to build out appropriate client- and server-side validations.

And its extremely extensible and customizable even beyond that. Cudos to Daniel Gredler for putting this together.

Tapestry 5 Progress: Class Reloading

Hit one of my first major hurdles for Tapestry 5 this morning: class reloading. Tapestry 5 periodically scans .class files to see if they have changed, and will clear caches and discard class loaders so that it can process the changes. I've finally gotten the code base to a point where I can demonstrate this and it works. And it's fast!

This is a huge productivity win: you change your classes and see the changes immediately. No restart, no redeploy. The same logic works for templates and other resources (you make the change, you see the change).

Speed is excellent; obviously, I have only a tiny fraction of Tapestry 5 implemented, and the page I'm using is very trivial (just a single component). However, even on my laptop, and with all debugging output enabled, refresh is instant.

By the way, here's my page template:

<html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd">    
    <head>
        <title>First Tapestry 5 Page</title>
    </head>
    <body> 
        <p>
            This is the <span style="color:green">First Tapestry 5 Page, ever!</span>.
        </p> 
        <p>
            Output from HelloWorld component:  <t:comp id="foo" type="HelloWorld"/>                
        </p>
    </body>`
</html>

And here's the HelloWorld component:

package org.apache.tapestry.integration.app1.components;

import org.apache.tapestry.MarkupWriter;
import org.apache.tapestry.annotations.ComponentClass;
import org.apache.tapestry.annotations.RenderTag;

@ComponentClass
public class HelloWorld
{
    @RenderTag
    void renderMessage(MarkupWriter writer)
    {
        writer.write("I Am HelloWorld");
    }
}

I need to do more experimentation; my environment is Eclipse 3.1.2 + Jetty (4) + JettyLauncher plugin. There's ample opportunity for the servlet container to screw us, in terms of their class loaders getting in the way (not showing file changes). Lots of people seem to use the Sydeo Tomcat plugin as well, so I need to check that.

Update to tapestry-testng

A new version of tapestry-testng has been upload. The version number (1.0.0-SNAPSHOT) has not changed, but there's some new features:

• Uses TestNG 5.1, the latest version
• Supports running tests in parallel

The previous versions of tapestry-testng uses a simple instance variable to store the EasyMock control. This is insufficient for TestNG, which creates a single instance of a test case class, and then will invoke test methods on it from multiple threads. This new vesion of the library stores the EasyMock control in a thread local variable.

However, I'm still not 100% certain this will work properly due to how TestNG operates ... it doesn't seem to invoke cleanup methods from the correct thread. See this forum posting. If TestNG is, in fact, broken, then we'll have to wait for a TestNG 5.2 that fixes the issue.

New version of tapestry-testng

I quietly released a nearly-final version of tapestry-testng a couple of days ago. The new version number is 1.0.0-SNAPSHOT.

The only significant change is that I changed the TestBase base class to extend from org.testng.Assert, so you can access all the assertion methods without doing a static import.

Metaprogramming Java with HiveMind

Holy time management, Batman! I'm going to get a bad rep at OSCON for running over time (last year, though, it was due to a late start).

Basically, I was pacing myself for a 60 minute session, not the 35 they give you. Way too many slides, too much intro, kept me from the cool stuff at the end of the session. Also, there were lots of good, informed questions.

My goal for the Tapestry session, later today, is to run under. But I don't see that happening.

Tapestry for PHP?

PRADO is a PHP framework expressly inspired by Tapestry. As you might expect, all I've had a chance to do is glance over the documentation, but it looks very nice, and their site is very professional and slick.

I suspect the relationship between PRADO and Tapestry is the same as between Tapestry and WebObjects ... the precursor "proves" the space is viable, but I doubt the implementation is all that similar, given the different languages involved.

Still, best of luck ... but don't expect any framework, on any platform, to keep up with Tapestry 5!

Tapestry 5 Updates

Even during OSCON, I've been churning out code for Tapestry 5.

The new Tapestry IoC container is rapidly coming together. The idea of replacing XML with Java classes (and naming conventions and annotations) is working out wonderfully. I'm busy putting together a version of configurations about now.

What I'm finding, as I code and also predict how the final Tapestry code will use the container, is some steep improvements.

In Tapestry IoC, injection isn't into your beans via property setters or constructors, the way it is in HiveMind and Spring. Instead, injection is via parameters to your builder methods. Injection via method parameters will also occur into decorator methods (the replacement for service interceptor factories) and into contribution methods (which contribute values into service configurations).

For example, in Tapestry IoC:

package org.example.myapp.services;

import org.apache.tapestry.ioc.annotations.Id;

@Id("myapp")
public class MyAppModule
{
  public Indexer buildIndexer()
  {
    return new IndexerImpl();
  }
}

The above defines a service "myapp.Indexer" as an instance of IndexerImpl. The equivalent in HiveMind would be :

<module id="myapp" version="1.0.0" package="org.example.myapp.services">
  <service-point id="Indexer">
    <create-instance class="IndexerImpl"/>
  </service-point>
</module>

That's already an improvement. By the time you start talking about dependencies, things get even better:

  public Indexer buildIndexer(String serviceId, Log serviceLog, 
    @InjectService("JobScheduler") JobScheduler scheduler, 
    @InjectService("FileSystem") FileSystem fileSystem)
  {
    IndexerImpl indexer = new IndexerImpl(serviceLog, fileSystem);
      
    scheduler.scheduleDailyJob(serviceId, indexer);

    return indexer;
  }

What's worthy of note here is how dependencies get injected in (as method parameters), and that lifecycle concerns about the IndexerImpl are separate from its implementation. We don't have to inject the scheduler into IndexerImpl in order for the Indexer to be scheduled by the scheduler ... that concern can be implemented only in the builder method.

To accomplish that kind of separation in either HiveMind or Spring would require quite a bit of hackery; say, creating a new, specialized kind of ServiceImplementationFactory (in HiveMind) that understood about talking to the scheduler. Lots of work for something that can be expressed so easily in a short, simple, testable Java method.

I think that we'll see this approach bear fruit in the form of fewer services to accomplish the same goals. It will allow for non-service objects to easily receive injected services ... such objects can be created "on the side" by builder methods (or contributor methods).

This is the theme for all of Tapestry 5: Simpler, easier, faster, more understandable, more powerful. Avoid XML. Improve productivity. Make the framework adapt to your classes and your methods, rather than the other way around.

Maven Thoughts

As much as I disliked Maven 1 , I've come to enjoy and rely on Maven 2.

It's getting things done for me. It's fast. The Maven plugin for Eclipse (that is, an Eclipse Plugin that support Maven, rather than the Maven plugin that generates Eclipse control files) seems to work well, automatically picking up changes to my pom.xml, as well as automatically downloading dependencies. And I'm using it in a tough way, given that I'm also using AJDT on the same projects.

I also think that the new "almost plain text" format is a godsend; it makes it much eaiser to quickly assemble good documentation. I'm trying to write documentation before writing code for Tapestry 5.

Still, maybe 20% of the time, I don't feel that I'm using a tool so much as appeasing a petty god. There's still a number of things I can do easily in Ant that seem to require writing Maven Mojos and plugins to do in Maven.

Synchronization Costs

I've been doing a bit of work on the Tapestry 5 code base. I'm really interested in making Tapestry 5 screaming fast, and since the code is based on JDK 1.5, we can use concurrency support. Previously, I've blogged about using an aspect to enforce read and write locks. I decided to write a simple benchmark to see what the relative costs were.

As with any benchmark, its only an approximation. I tried enough tricks to ensure that Hotspot wouldn't get in there and over optimize things, but you can never tell. HotSpot is a devious piece of software.

I got interesting, and strange, results:

For a base line, I executed the code with no synchronization whatsoever (simple). The cost of synchronization (synched) shows that synchronization is pretty darn cheap, just an increment on top of the baseline code. The aspect graph shows the cost of using the @Synchronized aspect to maintain a reentrant read/write lock (that is, shared read lock combined with an exclusive write lock). Finally, the rw graph shows the cost of writing code that maintain the read/write lock in normal code (rather than having it added via the aspect).

Synchronization has some overhead. Using the @Synchronization aspect is about 4x as expensive as just using the synchronized keyword on a method. Strangely, the aspect version operates faster than the pure code version for reasons I can't explain, except it must have something to do with how AspectJ weaves my code (a lot of code I write ends up as private static methods after weaving, which may have some runtime performance advantage).

These results demonstrate an important tradeoff: if your application only occasionally has multiple threads hitting the same methods, then you might want to choose synchronized, since you aren't in danger of serializing your threads. By serializing, we mean that only one thread is running and all other threads are blocked, waiting for that thread to complete a synchronized block. Serialized threads is what causes throughput for a web site to be bad, even though the CPU isn't maxed out ... it's basically, Moe, Larry and Curly fighting to get through a single, narrow door all at the same time (they race to claim the single, exclusive lock).

Tapestry, on the other hand, will have a number of choke points where many threads will try to simultaneously access the same resource (without modifying it). In those cases, a shared read lock (with the occasional exclusive write lock) costs a little more per thread, but allows multiple threads to operate simultaneously ... and that leads to much higher throughput. Here, Moe, Larry and Curly get to walk through their own individual doors (that is, each of them has a non-exclusive read lock of their own).

As with any benchmark, my little test bench is far, far from a simulation of real life. But I think I can continue to make use of @Synchronized without worrying about tanking the application. In fact, just as I predicted Tapestry 4 would out-perform Tapestry 3, I believe Tapestry 5 will out perform Tapestry 4, by at least as much.