Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Tuesday, June 20, 2006

Beyond domain specific languages

Most of my friends, growing up in the late 70's and early 80's, have played Zork or some other kind of interactive fiction.

Although the earliest adventures used just a simple VERB NOUN syntax, the Infocom games had much more powerful parsers that could understand more complete and natural inputs such as "take all the rings but the silver one" or "put the red battery inside the lantern".

In high school (say, around 1982), I wrote a very stupid, very simple adventure game, "Obelisk Adventure", in PDP-11 Basic. It had pointless quests, a maze with a big nasty rat (the maze wasn't mappable, because it randomly moved your stuff around). I think I also remember an endless hallway (poorly implemented). I also implemented a few similar adventures on my home computer (first a Challenger 1P, later an Atari 800). This was my claim to fame for a while, as pathetic as it appears in retrospect.

These games didn't go away after Infocom and the other publishers disbanded due to the onslaught of more graphic games (such as Castle Wolfenstein and, eventually, Doom and Quake). The underlying virtual machine was reverse engineered and an open source community grew up around virtual machine implementations, as well as languages and tools that compiled down to that machine: Graham Nelson's Inform.

The Inform language is a mix of general purpose features, and a lot of very domain specific stuff -- specific to the idea of simulating a world of rooms, objects and actors, and specific to the hooks of the natural language parser. Here's some Inform 6 source, stolen from the Wikipedia entry:

Constant Story "HELLO WIKIPEDIA";
Constant Headline "^An Interactive Example^";

Include "Parser";
Include "VerbLib";

[ Initialise;
    location = Living_Room;
    "Hello World";
];

Object Kitchen "Kitchen";
Object Front_Door "Front Door";

Object Living_Room "Living Room"
    with
        description "A comfortably furnished living room.",
        n_to Kitchen,
        s_to Front_Door,
    has light;

Object -> Salesman "insurance salesman"
    with
        name 'insurance' 'salesman' 'man',
        description "An insurance salesman in a tacky polyester 
              suit.  He seems eager to speak to you.",
        before [;
            Listen:
                move Insurance_Paperwork to player;
                "The salesman bores you with a discussion
                 of life insurance policies.  From his
                 briefcase he pulls some paperwork which he
                 hands to you.";
        ],
    has animate;

Object -> -> Briefcase "briefcase"
    with
        name 'briefcase' 'case',
        description "A slightly worn, black briefcase.",
    has container;

Object -> -> -> Insurance_Paperwork "insurance paperwork"
    with
        name 'paperwork' 'papers' 'insurance' 'documents' 'forms',
        description "Page after page of small legalese.";

Include "Grammar";

And you can do a lot with that language, and I've occasionally looked into trying my hand at it. But it never seemed like a good use of my time (if I'm not working on Tapestry, I try to find things that get me away from my computer, and preferably, out of my house).

... so I was stunned and amazed when I saw the new version of Inform, Inform 7. The language above is gone and replaced with a natural language of tremendous power and flexibility. The same example, also off Wikipedia, in the new language:

"HELLO WIKIPEDIA" by A Wikipedia Contributor

The story headline is "An Interactive Example".

The Living Room is a room. "A comfortably furnished living room." The Kitchen is
north of the Living Room. The Front Door is south of the Living Room.

The insurance salesman is a man in the Living Room. The description is "An insurance
salesman in a tacky polyester suit. He seems eager to speak to you." Understand "man"
as the insurance salesman.

A briefcase is carried by the insurance salesman. The description is "A slightly
worn, black briefcase." Understand "case" as the briefcase.

The insurance paperwork is in the briefcase. The description is "Page after page of
small legalese." Understand "papers" or "documents" or "forms" as the paperwork.

Instead of listening to the insurance salesman:
    say "The salesman bores you with a discussion of life insurance policies. 
    From his briefcase he pulls some paperwork which he hands to you.";
    now the player carries the insurance paperwork.

Graham's goal was to allow non-programmers to write interactive fiction. The "code" is readable by human and compiler alike. Many of the examples in the documentation maintain this look, even when doing complex things like adding new verbs to the grammar (though some of the advanced examples are less natural language, and occasionally some Inform 6 code is injected as well).

What's important is that is not COBOL. It's not complex and rigid and verbose ... it is, in fact, very concise and the parser is very, very flexible and adaptive to the user. For example, you can easily talk about related nouns in a pretty random order. By editting the source, you can discuss the briefcase before describing the insurance salesman ... I tried this, juggling the order of the paragraphs in the example and the game still compiled and worked identically.

It also has a lot of cool features, such as instead of reading the letter the third time, say "Re-reading the letter isn't going to change what it says." The language is expressive enough to understand lots of dependent information, such as actions occuring in sequence, related to the "game clock", or repetition. Much of the game logic takes the form of "before" and "instead of" rules around normal actions, built into the language (and its standard library).

This language is partnered with a special purpose IDE and reams of excellent, hyperlinked, integrated documentation and examples. Further, the IDE has built in regression testing capabilities (you can play a game within the IDE and record the responses, then later play back the game after changing the source). The IDE also generates maps and indexes of the game.

Sure, he's been working on this for a long time (Inform 6 is nearly ten years old). But the possibilities of this, taken out of this specific domain, are impressive. Imagine writing complex behaviors in succinct natural language instead of verbose XML. I'm normally against MDA approaches, but I think this kind of natural language deserves a careful assessment to see where it can be used within the enterprise.

Saturday, June 10, 2006

Teamwork Live --- Powered by Tapestry

And yet another very nice Tapestry application: TeamWork Live. This was created in San Francisco by CollectiveSoft and is meant to be a competitor to Basecamp.

Friday, June 09, 2006

Vaisala StrikeNet online

The "little" project that's taken up a lot of my time over the last year, Vaisala StrikeNet is now online. Vaisala is my client in Tucson, AZ that I've occasionally mentioned. It's a bit of a niche application (Vaisala tracks lightning strikes across North America, mostly for use by the insurance industry) but it is written using Tapestry 4 ... in fact, I made improvements to Tapestry 4 based on "rough edges" I found while coding this application.

Monday, June 05, 2006

Whoa ... Spring doesn't lazily instantiate beans?

Just stumbled across a blog about Lazy Bean instantiation in Spring 2.0. This is kind of funny to me ... lazy instantiation is so important, so part of the base line of IoC container functionality, that I just assumed Spring already did this.

Update: Spring has had lazy instantiation since at least 1.2, but it isn't on by default.

For the record: this is one of the essential services provided by HiveMind since day 1. HiveMind lazily instantiates everything it can, and is smart, using a pair of proxies for efficiency.

Why a pair? For threading efficiency. The outer proxy is visible to the world and delegates (initially) to the inner proxy. The inner proxy has its methods synchronized as it is responsible for thread-safe lazy instantiation. Once the service (and its interceptors) are instantiated, the inner proxy replaces itself inside the outer proxy. That is, once the service is instantiated, the outer proxy delegates directly to the service implementation, and the inner proxy is no longer needed (it is released to the garbage collector).

Doing things this way is a great idea, but not my great idea. It was suggested a long ways back by someone in the HiveMind community. I'd like to extend proper credit on this, but my memory is weak.

Using double proxies is a very powerful technique, since it ensures thread-safe, just-in-time instantiation of the service, without paying the cost of synchronizing every method in the outer proxy. It's an example of what an IoC container buys you ... I don't think you'd want to code three implementations of every service interface manually, but if you skimp, you undercut the performance and scalability of your app. Using HiveMind, two of the three implementations (the outer and inner proxies) are just provided for you.

So, that's a new answer to one of the more frequent questions posed to me: Why does Tapestry use HiveMind and not Spring?. A: Spring does not provide all the capabilities that Tapestry requires, such as lazy instantiation. Tapestry consists of about 200 services, but very few of those are needed at startup, and a percentage will not be used in most applications. Lazy instantation is a huge win for Tapestry.

Futher, HiveMind's approach to lazy instantiation and proxies means that you can have mutually dependant services ... services that are injected into each other. The proxies, and the lazy instantiaton, means that you bypass the normal chicken-and-the-egg problem of which service to instantiate first. I've used this technique to break untestable, monolithic code into two halves that can each be properly unit tested.

Back to Spring ... now that it looks like Spring 2.0 has lazy instantiation, I have to question the fact that it defaults to OFF.

Sunday, June 04, 2006

And we're back ...

Just got back from three weeks away from everything: first a week at JavaOne, where Tapestry received a Duke's Choice Award in the open source category. From there, it was two weeks on the island of Hawaii (the "big island" ... it's about the size of Connecticut). That was two weeks where I had virtually no internet connection (certainly not at the cottage I was staying at) and really, really didn't even think about Tapestry. Instead, it's been horseback riding, hiking, snorkeling and boogie boarding. Sun, surf and sand. That's quite a change, and a good break (normally, I close my eyes and start seeing code). This was good for me, I'm feeling just a little less frantic than before ... I've been doing too much for so long that I've forgotten what it means to relax. I'm literally tan, fit and well-rested.

I'm also pretty much done with my work at Vaisala, with that app going live in a couple of days. I'm looking forward to a chance to focus on Tapestry full time for a bit, I have code for Tapestry 5 to write, and updates to labs and examples and documentation, new sessions to write (such as for OSCON 2006). Meanwhile, Jesse and Brian have been kicking ass on Tapestry 4 and Tapestry 3, and Geoff looks ready to get Spindle upgraded to Tapestry 4. So there's a lot going on.

I'm also fired up to get people's attention on Tapestry. We need more articles and more evangelism and more books on Tapestry and I'll have more time to spearhead and motivate people on those lines. I'm already beginning to think of 2006 as the Summer of Tapestry.

Tuesday, May 16, 2006

Tapestry: Duke's Choice!

In something that was a bit of a surprise, even to me, Tapestry won a Duke's Choice award for innovation at this years JavaOne.

They gave me a big, wacky Duke statuette (photos to follow). I mean, I'm going to have to hire a pack mule to get it back to Portland. I also had a chance to chat with James Gosling about Java. I complimented him on the language and told him how much fun I'm having with it, which he seemed to like. On the other hand ... when I mentioned wanting "all the goodness of Java, but a little less typing", ala Ruby, he went a little cold. I didn't realize until this moment that he might have thought I was referring to object typing (an issue for another day) when I was, in fact, talking about keystrokes!

Meanwhile, I had to drop off the statuette in the room, so I've probably missed the Java bloggers meetup at the Thirsty Bear. We'll see if I can catch the end of that.

Been having a lot of fun so far ... maybe tomorrow, I'll even make it to a session!

Monday, May 08, 2006

NFJS Meltdown

I had a "perfect storm" of technical problems at yesterday's No Fluff Just Stuff which, sadly, scared away part of the audience. I had just re-installed Eclipse on my laptop, reorganizing my plugins into multiple extension folders (so make my eventual upgrade to Eclipse 3.2 easier) and I inadventently installed a new version of the Eclipse Jetty Launcher plugin, version 1.4, that is not compatible with Eclipse 3.1, just with 3.2. Ouch!

So, a lot of fumbling there that got in the way, took up time, and put me off my game. But people were still very interested and involved, with good questions. I have to think about the JavaScript stuff though ... it may just be too much for people who haven't seen Tapestry before.

See folks at JavaOne!

Tuesday, May 02, 2006

Synergy

So I find myself with a crowded desk: one laptop, a mouse for the laptop, a keyboard, mouse, and two LCDs for my desktop. It's getting crowded, and it gets annoying to switch between different keyboards.

Worse, I do all my Thunderbird email just off the laptop (though I use GMail on either or both). That's a problem when I need to copy text from the desktop to the laptop so I can mail it.

Solution: Synergy -- an open source tool that links my computers together.

Synergy allows me to use my desktop keyboard and mouse on both systems. The mouse travels off the left side of my desktop screen onto the right side of my laptop screen. Focus follows mouse, at least in terms of system-to-system, so I can type on one system (say, the desktop), move the cursor over to the laptop, and type into the active window there (without clicking). Synergy even updates window decorations.

Better yet ... Synergy supports cut-and-paste of text between the two systems. So I can copy text out of my browser on the desktop and paste it into compose window on the laptop. I had thought about using a KVM switch at one time, and this kicks its ass! In fact, had I discovered this a few weeks ago, I might not have bought a mouse for the laptop.

Not an issue for me, but it's also cross-platform. It supports Windows, Linux and (with some problems) Mac OS X.

Monday, May 01, 2006

Tapestry 5 Class Reloading

One of the big advantages of the scripting approaches to Web development (including JavaServer Pages at one extreme, and Ruby on Rails at the other) is the velocity of change: you can change a source file (a JSP, a Rails template, or even a Rails class) and see the change immediately.

Tapestry has traditionally been more aggressive at caching. Once a template or a XML file has been loaded into memory, it's stuck there. During development, you can use the -Dorg.apache.tapestry.disable-caching=true trick to turn caching off, but this not only slows down every request, but includes a memory leak that will eventually tank the application. It also does not reload classes the way it reloads templates and XML files.

In my quest to create a Java web development environment as compelling as Rails, one of the first things to tackle is this aspect of development: effective and efficient reloading of component classes.

The first pass at that code is now in the repository. Component classes are loaded in their own class loader (this is also necessary for the Tapestry AOP code that transforms classes as they are loaded into memory). When any transformed classes are changed externally, the class loader, as well as all instances derived from those classes, are discarded and a new class loader is created.

This will work quite well, far better than Tapestry 4's development mode. In production, you'll just throttle down how often Tapestry checks to see if underlying files have changed.

What's interesting is that I've been working, off and on, on this code base since mid-February. This compares to how long I spent on the initial prototype of Tapestry way back in January 2000, where I spent a couple of weeks of furious coding just to get to a simple "Hello World". In those couple of weeks, I "invested" Tapestry with many of the features that would grow with it, and support that growth, over the intervening years: the component hiearchy, the original and primitive form of templates, component parameter bindings, page loading, external XML page and component specifications, and other things long forgotten. To me, it was like winding up a spring ... all that upfront effort paid off with a basic design that was "right enough" to keep Tapestry innovative for many years.

The reason I'm starting with a new code base for Tapestry 5 is that it's time to wind up that spring again. The couple of design errors, only apparent after the fact, in Tapestry 4 are all but insurmountable without a fresh start (this primarily includes the requirement to extend base classes, but there are many more subtle things that need addressing). Further, the fact that I've spent a chunk of time getting the basic class loading and AOP support in place, the fact that anything web application is still weeks or months off, is actually a Good Thing. The spring is going to be wound nice and tight, full of energy for years to come.

Wednesday, April 26, 2006

Gambling on AspectJ

Squeezed in with everything else that's going on (the end of one client project and a lot of personal and business travel), I've been working on the start of the code base that will be Tapestry 5.

I think it is going to be a monster. In a good way. More on that later.

Tapestry 5 is targetted at JDK 1.5 and above. That means annotations, and not XML, will be the rule of the day. JDK 1.5 also means the use of Doug Lea's concurrency support, now java.util.concurrent.

Further, this is a chance for me to dip my toes in the Aspect Oriented pool.

I can picture the reaction: "Howard, that's the wrong 'A'! AOP is so ... 2004? Shouldn't you be focused on Ajax?"

However, the AOP support actually aligns nicely with much that I've done with HiveMind, using Javassist. It's been interesting to see the kind of things you can do statically, at build time, using AspectJ and how they compare to what you can do dynamically, at runtime, using HiveMind. Each approach has merit in different circumstances, and I'm trying to find out exactly where the lines of demarkation are.

For example, I've been doing a lot of defensive programming. So I've been creating aspects to help with that. It's been relatively easy to write aspects that inserts null check code into each non-private method. I like the don't accept null, don't return null coding approach, and my aspect allows me to ensure that all my code works that way. Further, for the rare cases where I want to allow null, I can place a @SuppressNullCheck annotation on a class or individual method.

I could do the same thing using HiveMind ... but I'd really be restricted to applying it to HiveMind services, since it would take the form of an interceptor. Tapestry tends to have lots of data and modeling objects in memory, that would benefit from these checks as much, or more so, than the service code. AspectJ is a better fit there.

I'm also doing some interesting work to use annotations to control concurrent read/write access to my classes.

I'm finding the mix of aspects and annotations to be very powerful. I use type annotations to narrow the set of classes to be affected by the aspect, and use method annotations to include or exclude individual methods. In my case, I have a @Synchronized annotation that indicates a class can have some of its method synchronized, and I have @Synchronized.Read and @Synchronized.Write to control which methods require a read lock, and which require the exclusive write lock.

I'm pretty happy from the point of view of getting more functionality (and, more robust functionality) from less code. Aspects are another approach to doing things that I normally associate with components and layering. The gamble part is how I'll feel once I'm trying debug into and through AspectJ-generated code. It becomes a bit tricky to figure out exactly what's going on once you've let AspectJ work things over.

I've also found that AspectJ really wants to work at the method level, when some of the things I want to do (such as validating individual parameters) are done at the individual parameter level. For example, I'd like to create method advice as the combination of a particular method and a particular non-primitive parameter of that method ... but the best I can do is advise the entire method and recieve all the parameters as an object array (whether they are primitive or not).

I have found the AJDT plugins for Eclipse to be a slight bit creeky. You definately want to upgrade your Eclipse to 3.1.2 (the latest and greatest). The visualization is great (when it works), as is the visual annotations of advised methods. There are numerous annoyances when editting aspects and browsing source, and I often have to perform clean builds of my code, something I hardly ever do when not using AJDT.

Thursday, April 20, 2006

Update on Tapestry @ OSCON

Earlier I had blogged about my frustration at not getting to speak at OSCON 2006. Well, word of my little outburst on this blog has trickled out to the key folks at O'Reilly and now both of my sessions are back in. They apologized for the lack of depth in the Java track, citing technical and procedural problems with that aspect of the conference (made that much worse by Daniel Steinberg's personal tragedy this year). They are working to make amends by inviting several prominent Java speakers to fill the gaps.

I'll have two sessions this year:

Wed 10:45 8588 - Metaprogramming Java with HiveMind and Javassist
Wed 2:35 8904 - Building Java Web Applications with Tapestry

This is great news. OSCON is a fun convention and it's about two miles from where I live. Maybe I'll get to ride the Segway again!

Wednesday, April 12, 2006

Java isn't Open-Sourcey Enough for O'Reilly

Let's just break the cardinal rule: don't blog when you are upset.

Both my sessions for this year's OSCON were rejected. Not just an improved, updated and Ajax-ey Building Web Applications with Tapestry, but a very differently scoped Metaprogramming Java with HiveMind and Javassist.

For O'Reilly ... if it doesn't say Ruby, it's not open source enough! This is doubly dissapointing, because last year's session went well (and turned out to be lucrative), and OSCON is held in Portland, OR ... just 10 minutes away by MAX.

Wednesday, April 05, 2006

Tapestry @ JavaOne Sessions

There are three sessions at JavaOne this year that will be of interest to the Tapestry community. All three will be held in Esplanade 307-310 (which was, I believe, where last year's Web Frameworks Smackdown took place).

Wed 17th 4pm RAD Frameworks Web Tier
Wed 17th 7:30pm The Component Edge: Creating and Using Components With Tapestry (BOF)
Thu 18th 10:30pm Trails BOF

I'm only involved in the Tapestry BOF; Chris Nelson (creator of Trails) will be presenting at the other two sessions.

I'll be arriving in San Francisco on the 14th and departing on the 19th. See everyone then!

Tuesday, April 04, 2006

Dissing Subversion is a bad call

Elliotte Rusty Harold:

The server side of Subversion needs a serious rethink, though. Currently you almost have to have a dedicated Subversion server and a fulltime Subversion administrator. That end needs to get about one thousand times simpler.

Howard Lewis Ship: Huh? I've had exactly one problem with Subversion in over a year of heavy use, that was solved entirely by upgrading to the latest recommended version of the server. You start it up, do a minimal configuration (a passwd file), and let it run. I also use Subclipse with repositories on javaforge.com and on apache.org. I've almost never used the svn command line, either.

Kind of dissapointing that ERH would bash a really great product like Subversion without even bothering to justify his erroneous conclusions. But he's bashed other cool software before.

Monday, April 03, 2006

tapestry-testng

This is another small library at Tapestry @ JavaForge. Unlike many of the others, this library is used during testing, not during deployment.

If you are used to using EasyMock 1.1 in combination with the HiveMindTestCase base class, then much of this library will be familiar ... except that it uses EasyMock 2.0, TestNG, and a lot of JDK 1.5 generics and annotations to keep the code short and simple.

As with the rest of Tapestry @ JavaForge, this stuff is still very alpha ... but also very useful.

Saturday, April 01, 2006

New Tapestry bug fix releases out!

Two new bug fix releases of Tapestry are now available: Tapestry 3.0.4 and Tapestry 4.0.1. Not only did tons of work happen, including documentation fixes and other great stuff but ... I didn't do any of it! I pretty much haven't updated my own workspace since Tapestry 4.0 was released ... I've been working on new demo apps, new side projects at Tapestry @ JavaForge, some prototypes of Tapestry 5, moving Tapestry to a TLP, as well as client project work and my No Fluff Just Stuff presentations. But I haven't been working on the Tapestry code base itself.

The system works! If there was any doubt that Tapestry is more, much more, than Howard's pet project, the energy and vitality that Jesse Kuhnert, Brian K. Wallace, and the many contributors from the community have demonstrated should put an end to that doubt.

I can now, officially, walk in front of a bus. Tapestry will continue.

Wednesday, March 29, 2006

Cognition: Tapestry 4 + Hibernate + Spring + Eclipse

Cognition is a new open source product similar in spirit to Trails. Both are approaches using Tapestry and Hibernate to streamline the process of creating a "typical" web application. Trails is very domain driven, creating the database schema from the object model. Cognition includes graphical editors inside Eclipse to build the schema, and derives the object model from the schema. There's a really impressive viewlet showing how to create a simple app really, really fast.

I can't wait for some time to open up in my schedule so I can give Rails, Trails and Cognition a spin.

Tuesday, March 28, 2006

HTML A tag vs. POST

Just an observation. If it is so damned important that GET operations be non-state changing and idempotent (blah blah caching, design of HTTP, firewalls, etc.) ... if it is so damned important that you never change anything expect using POST (and then send a redirect afterwards) ... tell me why the <a> tag does not support a METHOD attribute, the way <form> does. I mean, think back a few years, at all the crazy tags Netscape and Microsoft put into their browsers, and they miss this? Still?

I mean, this hasn't changed in years, and has consistently held web development hostage to the use of JavaScript to keep any non-trivial page from featuring a big old submit button. Apparently, the Powers That Be are afraid that without a big old submit button, we won't realize that hitting the "delete" key is going to delete something.

Sure JavaScript is all pervasive now, and you can force a form to submit using JavaScript ... and the use of Ajax will eventually mean that any non-trivial operation will be coded using XmlHttpRequest (which will do a post). Someday. For users with JavaScript enabled. But I just want to be able to write:

<a href=". . ." method="post">delete this report</a>

Monday, March 27, 2006

Tapestry Support Network Live Again

Woops. I accidentally let the domain registration for the Tapestry Support Network site lapse while I was on the road. All fixed now! Time to put some new content up there.

Sunday, March 26, 2006

New version of tapestry-spring

I've built out a new and improved version of tapestry-spring yesterday and today. This is a tiny module that properly initializes Tapestry to allow Spring beans to be injected into Tapestry pages.

This one works first off! I now run an integration test to prove this; it starts up a Jetty instance and injects a Spring bean into a Tapestry page.

More importantly, this version addresses the prototype issue. Using the standard @InjectObject annotation messes up when the bean being injected is not a singleton. Non-singleton Spring beans, aka prototypes, must be re-acquired from the BeanFactory in order to get the correct, new version.

There's now an @InjectSpring annotation that does that; reading the property will, beneath the covers, always go back to the BeanFactory to obtain a fresh copy. No caching at any layer, no problems.

I just realized that I forgot to update the documentation; that will come shortly.

I also bumped the version number up to 0.1.2 to celebrate the fact that this code works. But it is still alpha quality!

I did some trickery (I believe) so that the non-annotation classes are compiled for JDK 1.3, and the annotation classes are compiled for JDK 1.5. Took a bit of a struggle with Maven, but it works. If you aren't using annotations, you need to use a bit of XML:

<inject property="myProperty" type="spring" object="mySpringBean"/>

Static imports and Java language evolution

It's interesting to see the differences between how you expect to use a new language feature and how you end up really using it.

For example, of all the new features in 1.5, the idea of static imports seemed to be the least useful. From the outside, it looks like you get to say "min()" rather than "Math.min()". Big woop.

But what I've found when coding using static imports is a new clarity to my code. Once you strip away the class names from static methods the part that's left starts looking a lot like new and extensible language keywords.

For example, here's a test case from some code I'm working on.

    @Test
    public void test() throws Exception
    {
        Method m = ComponentFixture.class.getMethod("getSpringBean");

        EnhancementOperation op = newMock(EnhancementOperation.class);
        IComponentSpecification spec = newMock(IComponentSpecification.class);
        Location l = newMock(Location.class);
        Capturer c = newCapturer(InjectSpecification.class);

        spec.addInjectSpecification(capture(c));

        replay();

        new InjectSpringAnnotationWorker().performEnhancement(op, spec, m, l);

        verify();

        InjectSpecification is = c.getCaptured();

        assertEquals(is.getObject(), "someBeanName");
        assertEquals(is.getProperty(), "springBean");
        assertEquals(is.getType(), "spring");
        assertSame(is.getLocation(), l);
    }

What I've found as I've been coding is that I make extensive use of static imports. First of all, Eclipse makes it easy to do (Ctrl-Shift-M on top of a static method converts it to a static import). Secondly, my personal coding style has been to use a goodly number of static methods (if I can define a new feature in terms of the existing public API of an object, and I don't expect there to be a need for subclasses to override, then I create a static method that takes the object as a parameter).

Those assert calls at the end are actually static methods on an Assert class. Some of the other methods, newCapture() and capture(), are also static. The newMock() calls are inherited from a base class. It actually looks better inside Eclipse, because the static methods are italicized.

My point is ... the code is looking more expressive to me, as some clutter falls away. Autoboxing reduces some more clutter. So does the new for loop, and variable argument lists. Generics are still something of a wash (you get more self-describing code by adding lots of clutter, but you gain by removing explicit casts). The end result follows my motto, though: Less is More.

Has this transformed the language? No, and perhaps that's the point. It's some incremental change, but it's makes for some small steps in the right direction. It's not quite the fluid flow of static class methods in Ruby (used for all kinds of meta-programming), but it's still nice.

On the other hand, Sun is much less aggresive in adopting changes to Java than, say, Microsoft. I hate to say it, but innovation (where innovation is defined as adopting features that other languages have had for a decade or so) seems to be occuring in C# before Java. In some cases, it is occuring in other languages that execute on the Java VM. The end result is the same sad story of Sun chasing Microsoft's tail.

I'd like to see some real improvements to the language. I want Ruby blocks and continuations, C# autotype variables, built-in Aspect support and, hey, maybe something I don't know about that will make my programming life better (maybe a pervasive hot class reloader). In this respect, Java always feels like a perpetual bridesmaid, never a bride.

Saturday, March 25, 2006

NFJS Examples available

I've now been able to build and deploy the examples from my talks at No Fluff Just Stuff. The version number is still 0.0.1 and probably will be for some time. You can obtain a pre-compiled WAR, or a source distribution (with out without the PowerPoint slides) from http://howardlewisship.com/repository/com/howardlewisship/nfjs-tapestry/0.0.1/.

Huzzah! Subversion woes fixed.

I was just starting to panic. I was unable to check out my NFJS example code onto my desktop (it's stored using SVN, using my laptop as the SVN server). I've had some problems with Subversion recently, but thought I had resolved them.

From Eclipse, and from the command line, I was getting a wierd error:

bash-3.00$ svn update
svn: Can't read from connection: Software caused connection abort

From what I can tell, this occured when pulling down some large PowerPoint presentation files. Of course, there's no way to determine exactly what file the failure occured on, or why.

No output in the Subversion.log, or the svnserve command line, or any useful output from svn command line (or the Subclipse tool). Feedback anyone?

I tried updating to the latest Subclipse, 0.9.108. No help.

Finally, I tried upgrading my SVN server to 1.3.0 and ... things are working again!. Supposedly, I could have stayed with a Berkley DB repository using 1.3.0, but I've gone through the work of converting to a file system repository (as one of my attempts to resolve this problem), and I can't see the advantage of moving back. In fact, if anything, SVN seems faster or more responsive using the file system.

I should finally be able to get those NFJS examples up on the web site.

Friday, March 24, 2006

Back from the road! / tapestry-spring plans

Huzzah! Watch out Portland ... I'm back.

I actually had an exit row and room to work on the flight back from Phoenix. I decided to take another look at tapestry-spring.

First off, please remember that it is alpha code! So the fact that it completely doesn't work shouldn't be a total surprise. I had packaged the critical hivemodule.xml file under WEB-INF, not META-INF. Chalk it up to force of habit ... that's what you do for Tapestry applications, but this is a standalone library.

The reason I didn't catch that in my integration tests was ... I'm a lazy, lazy man. I need to learn how to write proper integration tests for tapestry-spring using Maven. I've actually had some good luck starting up Jetty inside a (TestNG) test case and that's the likely course I'll pursue.

So, that's half the story. The other half is dealing with Spring's prototype beans. This was someting that completely surprised me about Spring, once people started to complain. If you define a bean as having the prototype lifecycle, it means that you get a new instance everytime you ask the BeanFactory for it.

I really dislike that approach, because it puts the client code in charge of managing the lifecycle of the bean.

By contrast, HiveMind covers similar functionality quite differently. When you get a service from the Registry (the equivalent of getting a bean from the BeanFactory), you are going to get a proxy. Same service interface, different implementation (brewed up on the spot). The lifecycle of the service is hidden inside this proxy. You can share this proxy around, pass it between threads, even serialize and deserialize it (I think ... there's a few issues around that) and it just works.

The rough equivalent of Spring's non-singleton/prototype beans are HiveMind services with the threaded lifecycle. When you invoke a method on the proxy, it finds or creates a per-thread instance of the service. The per-thread instance is cleaned up and discarded at the end of the request (it's effectively built around a servlet request/response cycle).

This is used all over the place inside Tapestry. What's nice is that a piece of code can treat a proxy to a normal service, and a proxy to a per-thread service identically. That concern (in the AOP sense) is buried inside the proxy. Makes testing easier too.

Now, back to Tapestry's @InjectObject annotation. It's just broken for Spring prototype beans, because it's built around HiveMind's design, not Spring's. So it gets the object out of HiveMind just once and holds onto it, passing it into pages and components via a constructor (this is part of Tapestry's enhanced subclass approach to AOP).

For prototype beans, that means that we get the bean just once per component, and are stuck with it for any instances of that component we instantiate. The same bean instance, once aquired from Spring, will be passed into each new instance of a given page or component.

So ... I'm expanding tapestry-spring to add a specialized annotation, just for Spring. @InjectSpring will create a synthetic getter method that always gets a fresh instance of the named bean from the BeanFactory. That should solve the problem in its entirety.

I just need to stuggle with Maven a little bit more; I want to create a single JAR, where part of the code is compiled with JDK 1.3, but the annotation part is compiled with JDK 1.5. I think I can do this, by having multiple source roots (so src/main and src/annotations) and some extra compile executions.

Ultimately, this code may move under the Tapestry top-level project at Apache, once that gets set up. In the meantime, living at JavaForge is perfectly ok.

But, in the meantime, I need to catch up on the new Doctor Who, waiting for me on my Tivo. I've been out of town that long.

Sunday, March 19, 2006

NFJS code and slides ... just a little longer

It turns out I won't be able to post the updated slides and code from my No Fluff Just Stuff sessions because I left a critical password behind on my desktop. I'm on the road still (a long trip!) and will see about getting this stuff in place this coming weekend. Sorry for any inconvienience.

Friday, March 17, 2006

Zillow.com on The Boston Globe

Just noticed an article in The Boston Globe about Zillow.com. Zillow is a real-estate property values search application; at its core is a Flash application, but all the necessary infrastructure around that is Tapestry 4. I'm sure Ben and Dion are wondering why it's Flash and not Ajax.

Bitten by IE once again

If there was ever a single piece of software I hated with a passion, it would be Internet Explorer. I had let my seething resentment for this abomination settle for a while, as I do all my browing and development using FireFox.

However, with my project developer hat on, I have to support IE. My client, of course, is interested in IE support (given their user base, IE use will likely predominate). On just one page of my application, we hit the Operation Aborted error. The symptoms of this is that a page paritially loads, then a modal popup announces "Operation Aborted", and when you click OK, you are sent to the "This page cannot be displayed" page. I'm still tracking down the documentation, but it appears to be about a race condition where JavaScript modifies the DOM before IE is ready for it.

Now, I would have thought Tapestry would be safe from this, because of its approach to JavaScript ... the fact that JavaScript goes in proper places, at the top of the document, or at the bottom, rather than scattered throughout the document.

Doesn't matter; this page uses a DatePicker component, nested within a few tables for layout (a new reason why tables for layout is a bad approach) and apparently that's enough to trigger this bug in IE.

Side note: I talk a lot about the importance of Feedback, that tools should clearly identify problems and guide you to solutions. On a grading scale of A - F, IE would receive the grade take out back and put down like a rabid dog on this issue. And many others.

I have a couple of leads on this bug:

I'm going to see if using the Tacos DatePicker will work better than the built-in Tapestry DatePicker.

Update: The Tacos DatePicker did the job. Better yet, the latest DatePicker (from Tacos 4 beta 2) is simply stunning from both a visual and a useability perspective.

Tuesday, March 14, 2006

NFJS examples ... not quite ready

Having a problem with Maven 2, so I haven't been able to upload the updated NFJS examples.

Wednesday, March 08, 2006

From the fanciful ideas category ...

I was just thinking about a kind of half-measure between normal Tapestry useage and Trails.

One of the tedious aspects of building a lot of web apps (using Tapestry) isn't the managing of data in and out of Hibernate or JDO, it's just the repetition of building a table, inside a form, with each row containing a FieldLabel and a TextField (or PropertySelection, or whatever).

Wouldn't it be nice if I could just plop the following into the middle of my form?

<span jwcid="@edit:EditObject" object="ognl:pojo"/>

And this magic EditObject component could build the rest for me? This, certainly, would leverage Trails code, or Trails-like code. I'm sure there would be additional parameters to control CSS, and to control which properties were to be editted. And, of course, some set of annotations to define the validation of those properties. Maybe even so carefully named Block components to provide row overrides? Again, very Trails.

I think this logic would kick ass when building prototypes.

I was just sending a reply to Matt Raible about Java web framework sweet spots. At the core of my response to why Ruby on Rails is gaining so much mind share is because its represents a solution, not a tool. The Java space, especially the open source crowd, has gotten really good a churning out extremely useful tools. However, we tend to leave the solutions to the motivated students. The lesson of Ruby on Rails is for us tool-makers to get fired up about creating solutions.

This is just the opposite of how Tapestry has evolved, which (of course) parallels the evolution of how my coding and design skills has evolved. Earliest Tapestry was a very pure tool, focused entirely on "animating" HTML tags, as well as the transient and persistent state management. Over time, the components evolved from a focus on a single tag to many tags, to entire behaviors (including early precursors to Ajax techniques). That's great, but it's been left to the imagination of the user to see how those tools fit together to allow you to create a useful application.

This is more than just a question of examples, it's really about the emphasis of the overall framework. "Here's how you edit your object (in one line)" should be the first thing new users see and learn ... giving the users the ability to exactly control the HTML should be lesson three or five or ten. That's where Trails is getting things very, very right.

Subversion: ouch!

So, all of a sudden, I'm having massive problems with my Subversion server. Basically, nothing works. I can't seem to check new files in (it appears to crash svnserve, resulting in broken pipe exceptions) and I also see problems checking files out.

I'm in the middle of a full backup of my laptop (before my big trip to Boston and then Tucson). I think, after that, I'll dump out my repository, and rebuild it as a file system (not Berkeley DB) version. I've heard people claim that SVN in server mode doesn't work well with Berkeley DB, but I had thought that was only when you have multiple users pounding on it.

This is frustrating, and bad timing. I'm concerned that I'll have data, or at least revisions, in SVN I can't access. We'll see. It's always something.

Anyway, this is why I haven't had a chance to update the code for the NFJS project to include the latest code and presentations. I can't get things into SVN so that I can properly build and deploy.

Update: It's possible that I have a bad sector on my hard drive (Acronis has found an unreadable sector ... it's impossible to say if this bad sector has anything to do with my Subversion repository). Either way, reading (if possible) the repository to a dump format, and building a new file-system repository, should be a reasonable approach.

Wednesday, February 22, 2006

Update to tapestry-flash

I've updated the build for tapestry-flash to compile for JDK 1.3. I haven't changed the version number, but Maven 2 should pull it down anyway, since the time stamp and MD5 have changed.

Gearing up for NFJS

If I've been a bit unresponsive lately, it's because I've been working full time++ for a client, and putting together new versions of my presentations for two upcoming No Fluff Just Stuff engagements: St. Louis and Boston.

I'm completely retooling my existing presentations on Tapestry and Tapestry components, and writing a brand new one about unit testing with EasyMock (which isn't about Tapestry per-se, but may include some details about testing Tapestry components).

The new examples will be available via my Maven 2 repository. I may even move the source code from my private SVN over to JavaForge at some point.

Tuesday, February 21, 2006

tapestry-spring: simpler and better

I've changed tapestry-spring to be simpler and better. It now leverages Spring's ContextLoaderListener, rather than trying to replace it. In addition, it is now compiled for compatibility with JDK 1.3.

Since it is so alpha, I haven't been bumping up the version number for these changes. I suspect a 1.0.0 release will come soon. This library is now down to one class, some XML configuration, and a little bit of test code.

Maven 2: Different compilers for main and test

I'm in a situtation where different parts of my code need to use different compiler options. My main code often must be targetted for JDK 1.3, whereas I often use JDK 1.5 features (such as annotations and generics) in my test cases.

As I'm slowly peeling back the layers of Maven 2, I am finding solutions to these kinds of problems. Elegant (if somewhat verbose) solutions.

It turns out that you can not only provide a configuration for a particular plugin, but you can provide the configuration for that plugin in the context of a particular goal (or goals). So my solution was:

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                        </goals>
                        <configuration>
                            <source>1.3</source>
                            <target>1.3</target>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
That is, when reaching the "compile" goal, use the provided configuration. In other compile situations, use defaults (in my case, inherited from a parent POM).

I'm still working out exactly how phase and goal interact. It seems like goals attach to different phases (to control order of execution) ... and you can name goals or phases on the command line. Then there's the question of how prefixes get mapped to plugins ... I feel I've only peeled back the first layer of this onion!

Sunday, February 19, 2006

Tapestry-Spring update

James Carman pointed out that I had mis-packaged the hivemodule.xml inside WEB-INF, not META-INF. This is what happens when you switch contexts 5,000 times per day. I've fixed this and updated the 0.1.1 distro in the repository. Also, I probably should be appending "-snapshot" to the version number (I have to see if that operates the same in the Maven 2 world as in the Maven 1 world).

Thursday, February 16, 2006

Updates to Tapestry @ JavaForge

I decided to move the home page for Tapestry @ JavaForge back to my web site, so I can control things a bit easier. Tapestry @ JavaForge is a small, but growing, collection of Tapestry extensions, designed to work with 4.0.

These projects are useful as themselves, but are also quite interesting as examples of how extensible Tapestry 4 is. One adds a new binding prefix, "prop:", that uses generated bytecode, not reflection, to read and update bound properties, and is designed as a replacement for OGNL in many simple situations. This is useful when performance really counts.

The second extension adds a new type of property persistence, "flash", that is similar to the Ruby on Rails flash storage ... data is stored on the server, but only until the next time it is used to render the page. The documentation explains how to combine the flash with the really easy redirect-after-post supported in Tapestry 4.

In other words, small but significant extensions to Tapestry's base functionality. And the configuration needed to make use of these? Drop the JAR onto the classpath. That's what HiveMind is all about. All the necessary configuration is encapsulated inside each JAR's hivemodule.xml deployment descriptor. It Just Works.

As importantly, there is now a Maven 2 repository for this work, http://howardlewisship.com/repository/. With a little work (described on the home page), you can set up your local Maven to pull down these files, just like any other dependency.

I'm a little better than luke-warm about Maven 2; it's a huge advance over Maven, but it has stability problems, much out of date documentation, and even more generated documentation with very little content. I guess it is encouraging people to guess and experiment, which I simply don't have the patience for right now. However, I do think there's a lot of promise in Maven 2, so I'll be sticking with it for a bit. I still indent to transform HiveMind 1.2 and Tapestry 4.1 into Maven 2 projects.

Tapestry promoted to Apache Top Level

Following our request to the Apache board, and a unanimous vote of the Apache Board, the Tapestry project is moving ... to the Apache top level. We've only just received notice of the vote, but very soon now, there will be tapestry.apache.org.

This isn't so much about Tapestry as it is about Jakarta, representing the fact that Jakarta is re-organizing into more of a "meta-incubator", with the goal of all succesful projects (outside of commons) moving up to the top level.

However, this is still a vote of confidence for Tapestry and the team and will make many things better/faster/easier for us. It's all good (but it's, yet again, more work for me!).

Monday, February 06, 2006

Why store passwords in the database?

I'm always amazed whenever I hear about some security fiasco where a whole bunch of user information, including passwords, is obtained from some unprotected database.

I mean, I may not be a security expert, but even I know that you don't need to store the actual password in a database to allow users to login in securely.

My standard approach is to store the MD5 checksum of the password, rather than the password itself. In fact, I go further; I build a string combining the user's login id and their password and generate and MD5 from that. This has the advantage that different users with the same password will have a different value stored in the database, making it that much more difficult to gain wider access, even if some other security flaw gives the black hats read access. It doesn't even give up the size of the password, since md5 checksum are always the same length, regardless of the number of bytes in the stream used to build the checksum.

This is still a naive approach; you can do more, including adding additional "salt" to the alogiritm (such as a random number, stored only on the server, that is also factored into the checksum). However, at the core of this approach is the desire to never store a password as plain text. Encrypt it, hash it, obscure it. All you need to do is prove that the user knows the password and you don't need to store the password in plain text to do that.

As I remember, this is the way that Unix has traditionally stored password data, so I continue to wonder whenever I see a design that stores passwords out in the open, waiting to be harvested by the black hats.

Friday, February 03, 2006

Take #2: Ubuntu

I eventually found out that VMWare and Mandriva (the successor to Mandrake) don't quite play well together -- there's no easy way to get VMTools installed, and without that, mouse and video performance is bad. Based on a few recommendations, I'm trying Ubuntu instead. So far, I've managed the necessary incantations to download and install Sun's JDK 1.5 but I've been annoyed by performance issues, even with VMWare tools installed.

Things run very, very slow, even at modest (1024x768) resolution. The mouse can't keep up with my, I click and drag and it see the move too soon after the click and starts to do a select area. You have to click the mouse, hold it still for noticable fraction of a second, then drag. My students will lynch me if I foist this upon them ... especially considering that this is on my monster Alienware system.

Based on some recommendations on the web, I'm updating to the 686 kernel right now, to see if that helps. The Mandriva install was much easier and more performant, but people say that Ubuntu is the one. So much to learn ...

Thursday, February 02, 2006

Capturing parameters in EasyMock 2.0

I love EasyMock, especially the new version, 2.0, which really takes advantage of JDK 1.5 generics. Without EasyMock (1.1) I don't think either Tapestry or HiveMind would be as high quality as they are.

But even with the friendlier 2.0 version, there's one difficult case: When the code you are testing creates an object and passes it to another mock object. With the built in tools, you can use the isA() argument matcher to check its type, but that's about it.

In my situation, the code I was testing was creating an interceptor and pushing it onto the InterceptorStack. The interceptor wasn't returned, just pushed, and the InterceptorStack was itself a mock. I need to get that interceptor object so I can invoke methods on it, to ensure that it was created properly.

My solution was to create an EasyMock arguments matcher that exists just to capture a single parameter value. Here's the class:

package com.javaforge.tapestry.epluribus.tx;

import org.easymock.IArgumentMatcher;

import static org.easymock.EasyMock.reportMatcher;

/**
 * An argument matcher that captures an argument value. This allows an object created inside
 * a test method to be interrogated after the method completes, even when the object is not a return
 * value.
 * 
 * @author Howard M. Lewis Ship
 * @param <T>
 *            the type of object to capture
 */
public class Capture<T> implements IArgumentMatcher
{
    private T _captured;

    public void appendTo(StringBuffer buffer)
    {
        buffer.append("capture()");
    }

    @SuppressWarnings("unchecked")
    public boolean matches(Object parameter)
    {
        _captured = (T) parameter;

        return true;
    }

    public T getCaptured()
    {
        return _captured;
    }

    public static <T> T capture(Capture<T> capture)
    {
        reportMatcher(capture);

        return null;
    }

}

When asked to match an argument, it returns true after storing the captured value for later.

The static capture() method is important, it's how we thread things together. Here's an example from my test case:

  Capture capture = new Capture();
  InterceptorStack stack = createMock(InterceptorStack.class);

  . . .

  stack.push(capture(capture));

  . . .

  TransactionalService interceptor = capture.getCaptured();

Again, while I'm training the method invocations on my mock, I setup the capture, using the static capture() method. Later, after I've invoked my test class (the TransactionInterceptorFactory), I can get that interceptor object that was pushed onto the InterceptorStack and invoke more methods on it. Seems to work like a charm!

Denim - sketch your website

I'm building out some new IP for Tapestry ... a funky way of saying, I'm building a new, better reference application. It's called ePluribus and it uses Tapestry 4, annotations, HiveMind and Hibernate 3; in the long run, it may also use Lucene and a smorgasborg of other frameworks. Eventually, I will use this code as the basis for a number of presentations and use it to improve my Tapestry Workshop. But right now it's still pretty formative.

One of the first steps in designing a web application is the site map; this is often a frustrating excercise with post-it notes or scraps of paper (or, god help you, sequence diagrams) that are hard for the developers to interpret, and pretty much impossible for the clients. For ePluribus I'm wearing many hats, one of which is to be the client, another to be the web designer. I also say ... use the right tool for the job.

As best I can tell, the right tool is DENIM. DENIM allows you to sketch out your site map (the UI is designed for a tablet, but works with a mouse). It's designed for very rapid prototyping. Your site map is a single document that you can scroll and zoom to access individual pages. You can literally scribble your site together, creating links and buttons and drawing lines to connect pages together. It uses a lot of gesture based input (again, good when you are using a tablet).

A key innovation is that DENIM can export a HTML prototype of your site! Here's a sample.

DENIM is free (it was created at the University of Washington) and is written in Java; can't seem to find anything about source code or licensing, however. It's so worth a look!

ePluribus is hosted on JavaForge. There's no home page yet (its under the Tapestry @ JavaForge umbrella). The source is in SVN as http://svn.javaforge.com/svn/tapestry/epluribus/trunk and can be viewed directly (though the HTML view seems to be out of date somehow!).

Tuesday, January 31, 2006

Tapestry at JavaOne 2006

I'm 50% for JavaOne this year; a BOF session for Tapestry ("The Component Edge: Creating and Using Components with Tapestry") was accepted, but a more introductory Tapestry session, like last year's, got passed over. I guess by JavaOne 2007 I'll be able to talk about Tapestry 5 :-).

As a BOF, there will be much more opportunity for interaction with the audience, and room for others to discuss what they are doing with Tapestry, which I think is exciting. No word on scheduling yet, beyond the May 16 - 19th for the overall conference. I probably won't stay for more than a day or two this year, as I have to be in London on the 22nd.

Friday, January 27, 2006

Tapestry/HiveMind Interview on Java Posse

The Java Posse just put up my PodCast interview about Tapestry and HiveMind that also touches on Spring, EJB3, WebObjects, JMS, Reflection ... you name it! I kind of expected them to edit it down a bit more than they did ... and they certainly left in a number of things I consider flubs! It's about 59 minutes long and was a lot of fun to do. Apologies in advance for everyone whose name I forgot or screwed up (yes, its Hugo Palma who's working on the Tapestry IntelliJ plugin).

Side note to the entire world: It's HiveMind; the "M" is upper case. Like my mother-in-law has said to my wife Suzanne: "If I had wanted to call you Suzy, that's what I would have named you."

Tuesday, January 24, 2006

VMWare a qualified success

I blogged previously about my experiments with VMWare, and now I'm actually using this approach to my Tapestry Workshop at a customer site.

I'd call it a qualified success and I will follow this approach further. Perhaps the biggest problem was the setting on the VM's memory size ... it was set to 512MB, but the client machines only had about 512MB of physical RAM and this caused a lot of thrash. Dropping this to 256MB (which can be done by editting the .vmx file, or as an option inside a launched VMWare image) made all the difference. This is certainly something that will take some care.

Performance seems to be reasonable. Of the ten students, eight are working fine, one has a few mysterious problems and may have to reload his image from the DVD and the last decided to "go it alone" and copy the labs off of the CD and work on his native desktop (in other words, follow the pattern I've used in previous Tapestry workshops).

Right now, we're using a Windows XP image and that's causing some problems; I'm in the process of building out a Mandriva Linux image instead ... no licensing concerns, and will probably outperform Windows XP by a good margin.

On the one hand, this client is a good choice for the experiment ... the desktops in their training center are uniform and recent (if not powerhouses). On the other hand, no previous clients I've trained had such a setup, so I'm still concerned about facing a more typical client ... one with a tangle of varied laptops and hand-me-down desktops of all shapes and descriptions.

Friday, January 20, 2006

Another article on Tapestry at DevX

DevX has just posted Rapid Java Web Application Development with Tapestry. It's a very fast paced intro to Tapestry and is balanced (yes, Tapestry does have its share of quirks!).

I've been doing my best to push Tapestry over the top for a couple of years now, ever since I left my last full time job and became a consultant. Tapestry really feels there, with more and more people jumping on the bandwagon (in a positive way).

Even here in Portland, I've already met with three different organizations that use Tapestry exclusively and love it. It's another sign that moving away from Boston was good for body and soul.

Monday, January 16, 2006

Getting started with VMWare

I got a great suggestion from one of the developers at shopping.com: Make use of the recent VMWare free player to setup the Tapestry Workshop environment. I had been aware of VMWare in the past (when smart people like Craig Dodson or Greg Burd swear by a product, you should take notice).

So what's VMWare? It's a virtual computer within your computer. It allows one physical workstation to act as if it were several different computers. This is incredibly useful in a large number of scenarios; my friend Scott was using it when developing Windows device drivers ... he could install the drivers into a virtual machine and when it blew chunks, instantly reset its state back to before the driver wreaked havok. People have used it to run multiple versions of Windows, just so they can run multiple versions of Internet Explorer for cross-release browser compatibility. You can also use it to run alternate operating systems ... run a Linux environment from inside windows, for example.

In fact, at this very moment, I'm installing Windows XP to a VM inside my new desktop ... even while iTunes is running on my non-virtual OS. It's even properly mixing the music with sound effects from the Windows XP installer.

My goal is to create a VMWare image containing my Tapestry Workshop environment. Using the free VMWare player, and a copy of my image, people will have the entire stack .. from the JDK, to Eclipse, to the plugins and projects, to Jetty and FireFox all pre-configured and installed and ready to start with the first lab. This has been taking as much as half a day to accomplish at most clients ... valuable time, and a distraction from people's excitement about learning Tapestry.

Thursday, January 12, 2006

Subclipse new project tricks

I go through a little rigamarole every time I start a new project in Eclipse; I use a Subversion repository (locally, or on Apache, or on JavaForge) and I use the Subclipse plugin.

Subclipse is nice, but weakest on the things you do least often, such as creating a project.

I always start in the SVN Navigator; I create my new folder for my project.

I then share the project; I chose the "Use specified folder name". Next, I hit the browse button and select the folder I just created in the navigator.

Back to the Share Project dialog; the cursor will be in the folder name field, and the text "New Folder" will be selected, ready for me to type "trunk".

When I hit OK, we switch over the a synchronize dialog to do the initial checkin. The bin folder will be in the list of resources to check in ... simply uncheck it for now. Then hit OK to check everything else in.

Because you didn't check in the bin folder, your project will appear dirty. That's OK. Now comes the real trick:

  • Execute a "Replace With Latest" (not an update) on your project.
  • Close and Re-Open your project (to get rid of the .svn folder that shouldn't be displayed, but is)
  • Now, use the Team > Add to svn:ignore context menu item on the bind folder
  • Finally, check in your changes (which will appear to be a change just to the project folder itself ... that's where svn:ignore data lives)

Why is this necessary? Somehow during the initial check in, the local project gets out of synch with the repository. I know not what or why, but it's been very consistent against every repository I use, so I think it is a Subclipse problem. If you don't do the replace with latest trick, you will get incredibly annoying SVN errors when you try to mark bin to be ignored ... you just won't be able to check in your project.

Maven and missing Java Transaction API JAR

I'm starting to work on a new demo for Tapestry 4.0 that will be based on Hibernate3, and I want to build on Maven. Of course, the first thing that happened is that I tried to have Maven resolve the dependencies and it tripped over the JAR for the Java Transaction API.

Now, a little background. The JTA is under some Sun license that keeps it from being distributed; so Maven has the POM for it in the central repository, but doesn't store the JAR file itself. So what do you do?

You have to get the JAR file yourself, and convince Maven to load it into your local repository.

Not that Sun makes it easy for you ... oh no. You have to click through a license agreement, then you get the class files, packaged as a ZIP file. This is insane! You'd think they would know what a JAR file is! Why not package the JAR inside the ZIP, maybe with a license and some documentation? Because that would make sense.

I suppose you could just rename the jta-1.0.1B.zip to jta-1.0.1B.jar and go from there. I chose to build a proper JAR first. I started by unpacking into a local directory, then used the jar command as normal:

bash-3.00$ ls -lag
total 0
drwx------+  3 None 0 Jan 12 18:27 ./
drwx------+ 22 None 0 Jan 12 18:27 ../
drwx------+  3 None 0 Jan 12 18:27 javax/
bash-3.00$ jar cf ../jta-1.0.1B.jar *
bash-3.00$ cd ..
bash-3.00$ jar tf jta-1.0.1B.jar
META-INF/
META-INF/MANIFEST.MF
javax/
javax/transaction/
javax/transaction/HeuristicCommitException.class
javax/transaction/HeuristicMixedException.class
javax/transaction/HeuristicRollbackException.class
javax/transaction/InvalidTransactionException.class
javax/transaction/NotSupportedException.class
javax/transaction/RollbackException.class
javax/transaction/Status.class
javax/transaction/Synchronization.class
javax/transaction/SystemException.class
javax/transaction/Transaction.class
javax/transaction/TransactionManager.class
javax/transaction/TransactionRequiredException.class
javax/transaction/TransactionRolledbackException.class
javax/transaction/UserTransaction.class
javax/transaction/xa/
javax/transaction/xa/XAException.class
javax/transaction/xa/XAResource.class
javax/transaction/xa/Xid.class

Next up, convincing Maven to put it into the repository in the correct place:

bash-3.00$ mvn install:install-file -Dfile=jta-1.0.1B.jar -DgroupId=javax.transaction -DartifactId=jta -Dversion=1.0.1B -Dpackaging=jar
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'install'.
[INFO] ----------------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO]    task-segment: [install:install-file] (aggregator-style)
[INFO] ----------------------------------------------------------------------------
[INFO] [install:install-file]
[INFO] Installing c:\temp\jta-1.0.1B.jar to C:\Documents and Settings\Howard\.m2\repository\javax\transaction\jta\1.0.1B\jta-1.0.1B.jar
[INFO] ----------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ----------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Thu Jan 12 18:29:55 PST 2006
[INFO] Final Memory: 2M/3M
[INFO] ----------------------------------------------------------------------------
bash-3.00$

And, with that, you have the JTA jar, in place, ready to use in your projects.

Is Tapestry "The" Web Framework?

Gregg Bolinger thinks so. I'm glad he's having such a good time with Tapestry!

Wednesday, January 11, 2006

Tapestry Get-Together / Portland, OR

I'm having a little Tapestry get-together meet-and-greet next week (Jan. 18th) here in Portland. This is just a chance for me to meet people in the area, with Tapestry being a convienient conversation starter. We'll be meeting at Henry's Tavern. Discussions should include who'se using Tapestry and how, and where Tapestry is headed in the future. Drop me a line and I'll add you to the e-vite!

Tuesday, January 10, 2006

Tapestry for IDEA

Hugo Palma is now working on an IntelliJ plugin for Tapestry: Tapestry for IDEA. He appears to be factoring out the non-Eclipse specific code from Spindle, and reconnecting it inside IDEA's APIs. It's not clear how far along this process he is, but he is promising to post screenshots shortly.

2006 looks like a true banner year for Tapestry!

Monday, January 09, 2006

Comments now moderated

Well, the latest scumbags have found a way to make life suck for everyone ... in this case, blogger.com is letting spammers post ads for DVDs on my blog. In the meantime, I'm now moderating comments.

Saturday, January 07, 2006

Tapestry on Slashdot

Is it a sign of my personal immaturity that seeing a Slashdot article on Tapestry made my heart skip a beat? This is Slashdot covering the DeveloperWorks article and caught me by surprise. Let the fud/counter-fud begin!

Phew! Tapestry 4.0 is final!

Tapestry 4.0 (final) has been released. This is a great relief to me, because I really think I could explode, or at least spontaneously combust, if this didn't happen.

I'm exceptionally proud of this release; to some degree, we've rewritten Tapestry from the inside out. The new structure, based on HiveMind, makes Tapestry exceptionally extensible, and performance appears to be better than Tapestry 3.0 (so much less reflection going on). More importantly, the coding model has improved quite a bit. Component parameters now just work ... no fumbling with "direction", listener methods are really flexible and easy to use, the validation framework is much, much simpler, and the annotation support (still optional in 4.0) is very succinct and code-focused.

We're already doing some planning for Tapestry 4.1 which better not take two years ... I'm hoping more like 6 - 9 months. I have several tasks on my plate:

  • A fast, useable, productized integration test suite (that can be used to test applications)
  • Convert to a Maven 2 build
  • Rework form support to eliminate the rewind phase
  • Remove the need for pages and components to extend from Tapestry base classes

Meanwhile, time to sit back and see what people make of this new release.

Wednesday, January 04, 2006

Servlet 2.5: Where's the regexp?

Seeing the new features in Servlet API 2.5, the feature I most needed, regular expression matching, was missing. Regular expressions are in JDK 1.4 and above (Servlet 2.5 requires JDK 1.5), so its pretty amazing that a basic feature like this is missing. Certainly, there's a long history of using regexp to map paths, as built into Apache (especially mod_rewrite).

I was really hoping for this feature, to support even friendlier URLs.

Other features I'd like to see:

  • Proper notifications about session synchronization events --- I want to know when an object is being de-serialized from another server in the cluster so I can set up some necessary ThreadLocals
  • Programatic login, and the ability to provide an application-specific login page --- I want to be able to use Tapestry's superior form support to manage logins
  • Failover notification --- I think servlets should support clustering without sharing data, but providing a notification when a failover has occured. Data could be stored in the HttpSession, but would not be replicated. This would give a good middle-ground between single-server and enterprise cluster.
  • Servlet meta-data access --- servlets should be able to find out about their URL patterns and filters

I probably could go on ... I've been working around the Servlet API for quite some time.

Meanwhile, there are some improvements. The DTDs have been simplified (allowing multiple URL patterns per servlet is a step in the right direction --- how about allowing the mapping right inside the <servlet> itself?) The new annotation support looks quite nice ... in fact, putting annotations on fields instead of on methods is the (long term) way to get Tapestry away from using abstract classes, and I can almost smell the bytecode enhancement in the approach implied by the @Resource annotation.

Setting up Tapestry

I had a present this morning, as I scanned my favorite web sites ... an article on DeveloperWorks: In tune with Tapestry by Brett McLaughlin. This is a nice, fully fleshed out article about how to set up Tapestry, build it from source, and run the demos and tutorials.

There are days when I feel the weight of the Tapestry community firm and square on my shoulders, and then there are great days like this ... where the community really gives back. These are the days that remind me of what a giant killer Tapestry can be.

Saturday, December 17, 2005

Tapestry 4.0 Real Soon Now

It's been an interesting week. First off, I had to leave my brand new apartment in Portland, OR after one night to come down to San Francisco for a three-day intensive Tapestry training session. Teaching Tapestry to twenty people in three days is a bit of a challenge, but the results were very well received; I understand that all new web development at shopping.com will be done using Tapestry.

Meanwhile, in the struggle to get Tapestry 4.0 out, the first vote for a final 4.0 release failed, with a veto by Kent Tong. At issue was the gaps in the documentation, particularily the documentation related to validation. This prompted new contributer Jesse Kuhnert to fill in the gaps there, so I'm in the process of producing a new release candidate, 4.0-rc-2, which will be up on the mirrors sometime tomorrow.

This does show that the process works ... but also underscores that the way many other projects function might not be a bad idea. Apache will generally release numbered releases at intervals, and after the fact elevate a release to "final, stable" status. Had we been following that scheme, we'd be at, say, 4.0.15 around now. If we vote that as a stable release ... well, we don't have to do any extra work beyond publicising it; it will already have been available, presumably, for a week or two minimum before such a vote.

On another front, I've been using Maven 2.0, as I try to rework HiveMind to build under Maven instead of Ant. For the most part, Maven 2 feels more like a finished work than Maven 1 ever did. I haven't been wringing my hands in frustration the same way. I just now downloaded the 2.0.1 release and will see if that fixes the few issues I have been encountering ... such as reports not been run and integrated into the site output.

This does tie together ... once HiveMind and then Tapestry are building under Maven, even having regular point releases will be much less important, since it will be quite easy for the average developer to pull down the source and build. Alas, Tapestry and HiveMind currently raise the bar for that a little too high for the casual developer.

Has anyone gone through the process of converting Forrest XML documentation to Maven XML documentation? They are similar is concept but slightly different in details; I'd like to save myself the effort of writing conversion scripts and stylesheets.

Monday, December 05, 2005

Moved to Portland

Well, now we've gone and done it. My wife and I have sold our house outside Boston and relocated to Portland, Oregon. Time to start over in an entirely different part of the country, one that seems to align better with our tastes, politics, and interests. Given the people we met at OSCON 2005 (also in Portland), I know there's a good community of open-source and Java developers around here ... I can't wait to start meeting them!

Tuesday, November 29, 2005

Two New Tapestry Committers: Jesse Kuhnert and Kent Tong

The Tapestry project has just added two new committers!

  • Jesse Kuhnert - Very active with the Tacos component library, which is the hub for Ajax components for Tapestry. He's got an inside line on what it'll take to make Tapestry the best framework for Ajax development.
  • Kent Tong - Active mentor on the user and developer mailing lists, Kent has been keeping me and the other Tapestry committers honest for quite a while now ... and he's written a great book on Tapestry 4.

Great things are afoot for Tapestry ... fresh blood, a final 4.0 release very, very soon now, and an increasing number of high profile sites in the pipeline (and no, I can't say more).

Thursday, November 24, 2005

Tapestry @ JavaForge

I'm just about done setting up Tapestry @ JavaForge, an auxillariy site for Tapestry components and extensions. I've been experimenting with Maven 2, so far with some decent success. I especially like the Wiki-ish "almost plain text" format for documentation. Maven 2 still has a number of teething issues, and I haven't even touched the critical multi-project support yet, but I'm cautiously optimistic.

No downloads just yet, but the source code is easily accessible via Subversion and builds using Maven, which is close enough.

Can you tell I'd really rather not be balancing my checkbook right now? Merry Turkey-Day!

No Tapestry at ApacheCon 2005

Hope I'm not disappointing too many people, but I will not be able to do the Tapestry Tutorials at ApacheCon on Dec 10th, as previously stated. They didn't get enough tutorial sign ups by their Nov. 12th deadline (ApacheCon does terrible marketing), and since I really hadn't wanted to do a tutorial in the first place, I offered to cancel rather than try and come up with a last-minute way to boost attendance.

I was somewhat looking forward to this, since I haven't done any speaking engagements in too long. But with Tapestry 4.0 in the final stages, plus the fact that, as I type this, I'm supposed to be stuffing books into boxes for my move to Portland, Oregon next week ... well, let's just say that skipping ApacheCon goes a small way towards easing my monumental stress level.

Wednesday, November 23, 2005

Woops! Killed JavaForge.com

I think I may have killed JavaForge. No, really. It seems to have blown up and crashed hard as I was uploading the tapestry-prop site tarball into their documenent management system.

I really want to like JavaForge because it is free, and because it allows Subversion hosting ... but any instability (it's been down for about 30 minutes now) is troubling.

Tuesday, November 22, 2005

And Apache's JIRA is down again ...

... and I was going to fix all those outstanding Tapestry bugs tonight. :-) But I can't. Sigh.

Monday, November 21, 2005

Documentation for Script Templates

We're in the final stages of Tapestry 4.0, trying to fix the most glaring documentation ommissions, and tidy up the bug list.

I've finally written documentation for the script template specification DTD, which is a very important file with the growing emphasis on JavaScript with web applications.

Tapestry has had, for a few years, some very advanced code for generating dynamic JavaScript to complement the dynamic HTML. It's centered in these script templates that take care of organizing the JavaScript into two large blocks (one at the top of the page, the other at the bottom) ... which is better than having it scattered about. As importantly, the JavaScript generation understands the need for uniqueness, to prevent name collisions in client-side variables and functions. This is the infrastructure that lets clever folks, like the ones at Tacos, create Ajaxian components that just work without any special attention by the developer ... regardless of whether there's just one such component, or dozens, on a page. Tapestry has the infrastructure to support this, with out requiring any special configuration of servlets or anything else.

Friday, November 11, 2005

Improving Tapestry performance

I just spent the week with a high profile client that is interested in potentially using Tapestry for a very large scale site ... millions of hits per hour. Their in-house framework is quite capable of operating at this scale, through a combination of draconian restrictions on database access and server-side state, and a total avoidance of any kind of reflective object access. These are people who literally cannot give an inch on performance.

One of the ideas that bounced around was something promised for some future release of OGNL: bytecode enhancement. That is, in some cases, OGNL 3 is expected to identify places where it can create a class on the fly to expedite access to a property, rather than always relying on reflective access as it does today.

Alas, that hasn't happened yet, and Tapestry is still using OGNL 2.6.7.

But, I thought, what if we created a new binding prefix to use instead of OGNL, for this purpose. Because of HiveMind, this approach can be packaged seperately from the framework proper, and plug right in.

... and it works. I built a little peformance test harness and tried to figure out how many nanoseconds it takes to perform an operation; an operation involves a read and then an update. Here's one of the operations from the harness:

        Op op = new Op()
        {
            public void run(PropertyAccessor accessor)
            {
                Long value = (Long) accessor.readProperty();

                long primitive = value.longValue();

                accessor.writeProperty(new Long(primitive + 1));
            }
        };

The PropertyAccessor object is either created from bytecode, or implemented using OGNL (so that we can make the comparisons).

I did a number of test runs, with a number of operations:

              10000 iterations |  Direct ns |    OGNL ns
------------------------------ | ---------- | ----------
                 name - warmup |    4288.00 |  847364.00
                          name |    1777.00 |   18426.00
                  int - warmup |    2891.00 |   81127.00
                           int |     838.00 |    7497.00
                 long - warmup |    2969.00 |   28207.00
                          long |     617.00 |    7256.00

             100000 iterations |  Direct ns |    OGNL ns
------------------------------ | ---------- | ----------
                 name - warmup |    4282.00 |  819634.00
                          name |     972.00 |    7527.00
                  int - warmup |    2947.00 |   74425.00
                           int |     242.00 |    5955.00
                 long - warmup |    2910.00 |   27492.00
                          long |     209.00 |    6046.00

             500000 iterations |  Direct ns |    OGNL ns
------------------------------ | ---------- | ----------
                 name - warmup |    4182.00 |  852125.00
                          name |     857.00 |    6756.00
                  int - warmup |    2958.00 |   81820.00
                           int |     170.00 |    5724.00
                 long - warmup |    2793.00 |   34990.00
                          long |     215.00 |    5785.00

          2,000,000 iterations |  Direct ns |    OGNL ns
------------------------------ | ---------- | ----------
                 name - warmup |    4251.00 |  843185.00
                          name |     823.00 |    6553.00
                  int - warmup |    2927.00 |   48788.00
                           int |     144.00 |    5799.00
                 long - warmup |    2961.00 |   34945.00
                          long |     180.00 |    6173.00

The results show that the direct access is around 10x faster than reflective access, which is in line with the general documentation about reflection in JDK 1.5. Still, I'm troubled that the cost per operation seems to continue going down as the number of operations increases. This could be the effect of hotspot (though the elapsed time seems short for hotspot to get very involved) ... or it could represent a problem in my performance test fixture.

To use this, you just use the prefix "prop:" instead of "ognl:". And, of course, it only works for simple properties, not property paths or the full kind of expressions used in OGNL.

I'm hosting the code on JavaForge and will make some kind of release available soon. Perhaps it will migrate into the framework proper at some point.

Friday, November 04, 2005

Further Down The Trail

Chris Nelson has published his second article on Trails: Further Down the Trail.

Seems like a lot of people are getting excited about Trails, and rightly so. I can see a large number of projects getting built this way. It's a great idea, it's developer-focused, it gets you great results fast. I've also seen Chris mention integrating Ajax components from Tacos. What's easier than using Tacos components for Ajax behavior ... using Trails and getting the Ajax stuff for free!

By the way, one of the most remarkable aspects of Trails is that Chris has been building Trails as a way to learn Tapestry. Either Chris is really some kind of comic-book alien machine super-intelligence (unlikely, I've met him in person), or Tapestry isn't quite as hard to learn as some people seem to think. Perhaps Chris had less Struts and JSP clutter to unlearn.

Sunday, October 30, 2005

A cool 1500

Just finishing up a fix for TAPESTRY-602 and, in the process, added the 1500th test to the Tapestry test suite.

Saturday, October 29, 2005

Even Easier Tapestry Examples

I took up an idea posted on the Tapestry User mailing list and, starting with beta-12, the Tapestry examples will be even simpler to obtain and run.

The new Tapestry examples distribution will be a slice of a JBoss distribution, with the Workbench and Virtual Library deployed into it. Yep, about 99% JBoss and about 1% Tapestry, but it means you can untar the examples distro and execute run.bat or run.sh and have it all up and running in less than a minute.

Once again, the less enlightened will bitch and moan about using JBoss. And once again folks, this is a demo. Everyone has their favorite container and I've gotten annoying flak in the past for not supporting all of them ... as if that was the point. In truth, the point is to get an easy to run demo. Perhaps someday I'll use Geronimo, because it is also an Apache project. But I go a ways back with JBoss, so it was easy for me to build and package, and is a good use of my very scarce time.

There is NO dependency between Tapestry and JBoss. Deploy wherever you want, but if you want a quick turnkey demo, download the demos.

Why I like Annotations

I've been working with JDK 1.5 annotations for several months now with exceptional results. Perhaps it's just a reflection of Tapestry, which has grown to use a pattern of design and development I've come to call composite coding.

Composite coding is a kind of intersection point between traditional class-oriented inheritance, aspect oriented programming, and code generation. This approach was already in place nearly two years ago, in Tapestry 3.0. When you define a class as abstract, and define transient and persistent properties (using XML) in Tapestry 3 what you are really doing is compositing your code with code generated by Tapestry.

This is not so much different from traditional approaches, where we composite the code we write with code from base classes often written by others. That's the nature of inheritance (and whether that is a good model for creating a framework is a discussion for another day).

Aspect oriented programming is also a way of compositing different sets of code together to form the final class definitions used at runtime. In fact, aspect oriented programming is such a general term that it easily encompasses what Tapestry is doing ... in fact, the uses of composite coding in Tapestry are very much within the domain of aspect oriented programming: cross cutting concerns related to page pooling and server-side state managements.

What I like about annotations, as applied to Tapestry 4, is that it integrates the code with the composite operations to be applied to that code ... that is, to make a property persistent, add the @Persist annotation directly to the method, rather than configure persistence elsewhere (in Tapestry 3, in a companion XML file).

One of the complaints of this approach is that it puts configuration data directly inside Java class files, where changing configuration requires a recompile and re-deploy of the application.

That's a pretty lame complaint and, to my ears, is an attempt to resist change. Sorry folks, get used to embracing change ... or get used to saying "want fries with that?"

Even in an extreme example, say the EJB3 @Table annotation, the problem isn't with the annotations ... it's with the framework that utilizes those annotations. In many cases, an annotation sets a default value ... one that may need to be overridden to match a particular deployment configuration.

In fact, this is only one step removed from the mess that was EJB 1 and 2 ... where the mythical application deployer role was responsible for configuring and deploying EJBs by configuring deployment details such as ... databases and tables. Sun dropped to ball on describing how this person did their job. In fact, the only effective way would be to explode EARs, including nested WARs and JARs, so that the ejb-jar.xml configuration files (and their many friends) could be edited, then repackage everything.

In my view, BEA, IBM and JBoss (in fact, the whole application server sector) dropped the ball by NOT providing a mechanism to override the defaults specified inside the ejb-jar.xml files short of exploding and repackaging.

Annotations are no different; tools and frameworks that rely on annotations should take into account the fact that deployment may need to change some of the configuration specified in the annotations. In other words, don't work directly from the code annotations, construct a model from the annotations, but allow other vectors for controlling that model before it is acted upon.

Yes, this is the model used in Tapestry 4, where an optional specification is parsed into memory, then modified to reflect information gleaned from annotations.

One of the major things to admire about the Ruby community is the emphasis on The Code Is The Thing. Nobody gives a sneeze at all the meta-programming in Ruby, because, in the end, they still have the standard ways to read and update Ruby object properties. JDK 1.5 Annotations are as close as Java currently gets to meta-programming and it brings the emphasis back to The Code, where it belongs.

In the past, I often was asked why Tapestry used so much XML. "Because it's convenient" was my response ... a convenient way to store some rich, hierarchical data. Well, annotations are even more convenient, and I think, more in the spirit of how we should be coding.

Thursday, October 20, 2005

Apress book on Tapestry

Just spotted this forthcoming book on Apress's web site: Beginning Open Source Enterprise Java: Spring, Hibernate, JBoss and Tapestry

Beginning Open Source Enterprise Java takes you through the construction of a complex enterprise Java application centered around JBoss, Spring, Hibernate, Tapestry, Ant, and other supporting tools for development and testing. This book is ideal if you’re new to Open Source Java, and want to build enterprise Java applications from scratch, using the full range of available Open Source tools and frameworks.

This book features the most successful and prevalent Open Source tools, along with some lightweight frameworks and tools. You’ll learn how to build a complete enterprise application, how to integrate the different Open Source frameworks to achieve this goal, and techniques for rapidly developing such applications.