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!

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


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.