For a good story of how Equinox helps, see Wayland Chan's Equinox to the rescue blog post.
This release's major new features are Tapestry 4.0 and WebWork 2.2.1 upgrades.
In addition, I changed to use Maven's
Standard Directory Layout. It makes IDE and using Maven plugins much easier,
so it's a natural progression.
This release does not contain Maven support for running the integration tests with
Cargo. This is because Cargo still seems
a lot more complicated with Maven than with Ant. Hopefully I'll be able to figure
out an easy way to get test-all functionality with Maven and Cargo in the next
release.
All of the frameworks used in Equinox, as well as its build/test system is
explained in Spring Live. A summary
of the changes are below (detailed release notes can be found in JIRA):
- Added custom exception page for Tapestry, as well as
tapestry-flash.
- Changed birthday date input to use WebWork's DatePicker component.
- Added support for pre-compiling JSPs when building with Maven (on by default).
- Added createDatabaseIfNotExist=true to jdbc.properties.mysql to auto-create the database when using MySQL.
- Changed classes that extend *SpringContextTests to use AUTOWIRE_BY_NAME so more than one instance of an interface is supported.
- Dependent packages upgraded:
- Cargo 0.7
- DisplayTag 1.1
- Hibernate 3.1.2
- Scriptaculous 1.5.2
- Tapestry 4.0
- WebTest build 1168
- WebWork 2.2.1
Download. For more information about installing the
various options, see the README.txt file.
Demos:
Known Issues: The Tapestry-Flash JAR was built with JDK 1.5 - so you'll need JDK 5 to run the Tapestry version. Howard Lewis Ship said he'd fix this tonight or tomorrow. Also, if you're on Unix, you'll need to run "ant fixcrlf" before you install anything. Finally, downloading dependencies might not work the first time. Running the "ant" or "mvn" command multiple times usually solves the problem.
See the roadmap for what's coming in the next release.
In addition to upgrading Tapestry last week, I also upgraded Equinox to WebWork 2.2.1 (from 2.1.5). The commit log can be found on Fisheye. The changes I had to make were pretty minor:
- WebWork 2.2.1 easily integrates with Spring - you just need to add
webwork.objectFactory=spring to your webwork.properties file. This isn't a whole lot different from 2.1.5, except that you can get rid of the SpringObjectFactoryListener from web.xml.
- ServletDispatcher has been deprecated in favor of FilterDispatcher - which should map to <url-pattern>/*</url-pattern>. Using a filter for the controller is an obvious improvement, and it's pretty slick how WebWork can now add CSS and JavaScript to your pages on-the-fly.
- WebWork now has a <ww:datepicker> component which makes it possible to do easily do popup calendars like you can with Tapestry and JSF. Unfortunately, it seems you still can't set a global date format using a ResourceBundle.
- AltSyntax is on my default, which means you'll need to change "'literal string'" to "literal string" and "variable" to "%{variable}". This is much easier to read and a welcome change. It's unfortunate that ${} can't be used, but that's JSP's fault, not WebWork's.
- FreeMarker is required, even if you're just using JSP. This is because the JSP tags' HTML is generated using FreeMarker templates (I think).
- The taglib URI has changed from "webwork" to "/webwork". I wonder why they don't use the full URL like most tag libraries?
- Exception mappings have been added so you can easily map a particular exception to a specific view. This allowed me to remove a custom interceptor I'd previously wrote.
- The DTD for xwork.xml has changed from xwork-1.0.dtd to xwork-1.1.1.dtd.
- The only issues I found were that the validator interceptor makes it difficult to override "excludeMethods" and client-side validation renders duplicate messages when you click submit multiple times.
- When I deployed the latest Equinox demo to Contegix, we had some issues with the stylesheet the datepicker stuffs in the <head>. Basically, mod_caucho 3.0.14 wasn't returning the proper content-type for the stylesheet (even though it was for the rest). Upgrading to Resin 3.0.17 with mod_proxy fixed the problem.
Hopefully this helps you upgrade to WebWork 2.2.1.
Last week, I upgraded Equinox from Tapestry 3.0.3 to Tapestry 4.0. The commit log can be found on Fisheye. Here are some details that might help you upgrade.
- Tapestry 4.0 doesn't support Spring out of the box. This was surprising to me b/c one of the advertised features of Tapestry 4.0 (or Hivemind actually) was native Spring support. Luckily, Howard released the tapestry-spring project which solves this problem. Dropping the JAR in your classpath is enough to get built-in integration. It'd be nice to see this library become part of tapestry (possibly in the tapestry-contrib.jar).
- Tapestry-Flash makes it easy to do success messages when redirecting. Furthermore, it's nice to see how to do redirecting w/o throwing a PageRedirectException.
- PageRenderListener has changed to PageBeginRenderListener.
- When using <inject> for a property, I had to remove any
public abstract void setXXX methods as I got an error otherwise. Luckily, the error message told me exactly what to do.
- Injecting dependencies during testing is fairly simple using the Creator class. Equinox's UserFormTest.java has a good example of this. I did have to create a MockRequestCycle and a MockPageService, but both were pretty easy to write.
- Friendly URLs are much easier to implement in Tapestry 4.0. However, Tapestry still doesn't allow you to use the same extension for everything - so I ended up with .html, .direct, .sdirect and .svc extensions. I'd prefer a single extension, but oh well.
- You'll need to change all your *.page files to use the new 4.0 DTD. I don't think this is absolutely necessary, but it does simplify things.
- As part of the 4.0 DTD, <property-specification> has changed to <property> and the "type" attribute is not allowed (b/c it's inferred using reflection I assume). In addition, <binding name="foo" expression="bar"> has changed to <binding name="foo" value="bar"> and <context-asset> has changed to <asset>. Also, <message-binding> has been removed in favor of <binding>. The userForm.page diff shows detailed changes.
- @Conditional has changed to @If.
- The issue where Tapestry sets the focus on the first required field still occurs. An easy workaround is to make the first field required.
- The @DatePicker component has changed from using the "format" attribute to using the "translator" attribute for formatting dates. The popup calendar also seems to have changed - I had to add new CSS rule to colorize the header properly.
Hopefully this simplifies your Tapestry 4.0 upgrade.
From Ted Husted on the Struts mailing list:
Seriously, hype aside, engineer to engineer, if we can use the new
standalone Tiles with WebWork, and use Ajax to store the state of UI
controls, what else do we need to do to make WebWork/Action 2 the best
framework for *everything*?
My reply:
The tag documentation (and documentation in general) for WebWork is
difficult to navigate. Struts' documentation has generally made it
easier to find stuff.
I think the hardest part of WebWork/Action 2 is providing the path for
migration. If Struts 1.x applications can run in Struts Action 2.x,
and users can create new Actions following WW's APIs - that will be
truly awesome.
Another that would be cool is smart defaults. For example, having
Actions that end with "Action" be available at the
"everythingbeforeAction" URL. Spring has something similar coming in
2.0 - and it's mainly just done by extending a certain class.
http://jroller.com/page/raible?anchor=an_example_of_smart_defaults
So if I have UserAction, it's automatically available at /users,
/user/edit, /user/save, etc. Default CRUD in a sense. No xwork.xml
required by default. But users can override. Default everything w/o
requiring annotations, but allow overriding. Or maybe there's
different default schemas - a CRUD one, store front, etc.
Ajax stuff that I think WW already has: in-page updates,
sortable/pageable lists with something like the displaytag - but with
Ajax. There's a lot of these components already available for this
stuff, so it might just be a matter of documenting how to integrate
them.
Promoting Maven 2 for building might be an easy way of promoting
inclusion of 3rd party libraries. Add 3 lines of XML, use this code
in your JSP/template, boom - you're good to go. Those that don't like
Maven can use the Ant tasks and pom.xml.
Archetypes could be pretty big too - create starter applications that
users can use. Even better, provide a means to upgrade the
archetypes. Of course, that might be a Maven thing - and editing
pom.xml to change versions really isn't that hard.
Above all else - to become the best MVC framework for Java -
documentation and easy migration are essential.
Just my $0.02 of course. 
What's your opinion?
A week ago, Apple announced that it was shipping MacBook Pros with faster processors. At the time, this seemed like an excuse for Apple to change the shipping date from February 15th to the 28th. Since I was already disappointed by the extra 2-week wait, I upgraded to the 2.16 GHz chip. This bumped my ship date back even further - to March 17th.
However, I just received an e-mail from Apple saying that my laptop has shipped! WTF? Either there's a glitch in their system or I'm gonna be one happy camper at the end of this week.
