Raible Designs

The Battle of the GZip Filters

When I first added a Compression/GZip filter to AppFuse, I used the one from Roller, which I believe Lance found in this book. This has worked fairly well since I added it in July last year. When I discovered that there were issues with it on Resin, I chaulked it up as "no big deal" since I don't use Resin anyway. But yesterday, when I discovered that it stopped my apps from displaying my 403 <error-code> page, that was the last straw. I remembered seeing the "Two Servlet Filters Every Web Application Should Have" article on ONJava.com about a different implementation, so decided to download the source and try it out.

I quickly discovered that this Filter does work on Resin, so that's quite a bonus. I've had issues getting Roller to work on Resin with the Filter enabled, so I might have to replace Roller's CompressionFilter. However, I did still have to change a few things to convince this Filter to satisfy my needs.

Here are a few things I discovered about this GZIPFilter vs. Roller's CompressionFilter:

• Don't download the GZIPFilter from the article. There is a newer version of the code. Not much has changed, save for an almost completely re-written GZipResponseStream.java file. This one supposedly does better handling of large files.
• This Filter has the same problem I experienced with Roller's CompressionFilter: JSP pages don't finish rendering when running my Canoo WebTests. I'm assuming that this is because the buffer hasn't finished spitting out HTML. I ended up writing a new isGZIPSupported() method (in GZIPFilter.java) to do the check for GZip support. This allows my webtests to run smoothly by disabling the filter for HttpUnit.
• This Filter shares another issue that I found in the CompressionFilter yesterday. When my webapp returns an HttpServletResponse.SC_FORBIDDEN error code (from trying to access a method that denies the users role), the Filter suppresses the error and the user is not served up the 403 error page defined in my web.xml. To fix this, I overrode sendError() in GZIPResponseWrapper.java and added a check for this error code in the getWriter() method.

Overall, I'm pleased with this code because I love the concept of GZip Filtering, and now it's not causing any conflicts in my app or targeted appservers.

GZIPFilter.isGZIPSupported(HttpServletRequest):

GZIPResponseWrapper.sendError(int, java.lang.String):

GZIPResponseWrapper.getWriter():

Cactus and Form-Based Authentication

Quick Summary: Did you know it's possible to login (with form-based authentication) before running each of your testXX methods in a ServletTestCase or CactusStrutsTestCase? Just add a "begin" method in your Base class, or in each of your Tests, and it will be called automatically, just like setUp() is called.

    public void begin(WebRequest request) {
        request.setRedirectorName("ServletRedirectorSecure");
        request.setAuthentication(new FormAuthentication("tomcat","tomcat"));
    }

Long and Winded: Yesterday, I began adding the "roles" attribute to my Struts action-mappings - to limit access for certain user roles (Yes, XDoclet 1.2 supports this). This worked great in my web UI, until I tried to run my StrutsTestCases. Access was denied because I was not logged in. Rather, I was "faking it" by retrieving a UserForm object in my setUp() method and stuffing it into the session [View Source]. This worked like a charm until I added the roles restriction.

Cactus has a nice feature: if you write a beginXX method, it will be called before your testXX method. In other words, begin = client, test = server. So I added a number of beginEdit, beginSave, etc. method to my Action Tests. Great - everything worked. But it was ugly to add all those beginXX methods. Then, via Vincent Massol's wisdom, I learned of the global begin(WebRequest wr) method. Now I simply have a begin() method in my BaseStrutsTestCase class, and everything works as smooth as pie.

    public void begin(WebRequest request) {
        request.setRedirectorName("ServletRedirectorSecure");
        request.setAuthentication(new FormAuthentication("tomcat","tomcat"));
    }

A couple of issues I discovered:

• If you have an Action that doesn't have any roles in any of it's mappings, this will fail, so you have to override the begin() method with an empty {} method in your *Test.class. I believe the error message was it couldn't find the SecureServletRedirector.
• You must define all the roles (you plan to authenticate with) in your Ant build.xml file. [Read More]
• My <error-code>403<error-code> is not working on AppFuse or the current real-world app I'm working on. [Read More]

All in all, I'm pretty pumped that Cactus makes it this easy to test my app in its true production environment.

Later: I figured out the source of the 403 error-page not rendering. Once again, my Compression Filter does more harm than good. I switched it out for a more recent GZIPFilter and the same thing happens. The good news is that the new filter works on Resin, whereas the old one did not.

A little EL Lovin' for the DisplayTag

Tim McCune submitted a patch for the Display Tag Library to add Expression Language support. I committed it today, along with a few other enhancements. You can read more on the displaytag-devel mailing list. Tim's patch was a nice clean approach to adding EL support. He just subclassed the existing tags and then evaluated the expressions. All I did to integrate was to create an "el" package under "tags" and added an additional .tld file. So there's really nothing that's taken away from the original tag library, and if you want EL support, you simply need to use the "*-el.tld" in your web.xml or change your URI to "http://jakarta.apache.org/taglibs/display-el". Of course, you'll need to include JSTL's JARs (standard.jar and jstl.jar) in your WEB-INF/lib to make this work. This patch included the ability to specify a titleKey attribute - a much asked-for feature.

I like Tim's approach so much, I might have to use it for Struts Menu. It's a slick way of supporting JSP 1.1 containers, and adding optional EL support for JSP 1.2 containers. I haven't had any feedback from the dev team, but hopefully this will make it into the next release.

WebSphere version 6.0 - when's will it release?

Today I discovered that WebSphere is one of the first appservers to support J2EE 1.4. Too bad it's a developer release and not a real release. At my current project, we've been developing on Tomcat 4.1.29 (and MySQL) because it's the only platform I've tested AppFuse on. We plan to migrate to WebSphere and DB2 in the coming months. They currently have a license for WebSphere 4.x, which I heard sucks - especially (IMO) because it only supports Servlets 2.2 and JSP 1.1. Luckily, the app we're deploying to production will be the first Java-based webapp, so we will hopefully be able to use WebSphere 5.1.

I just wish 6.0 was out as a real release, then we could start using JSP 2.0 and leave all those damn <c:out value="..."/>'s behind.

Back in Denver

We arrived back in Denver last night after a nice winter-weather week at the cabin. It's nice to be home and sleep in our own bed. Julie agrees and would add that it's nice to have indoor plumbing again. I hate the fact that I have all this e-mail to plow through and respond to. I like the fact that I'm super motivated to learn new stuff. So motivated that I ordered a few books from Amazon. I hope I can suppress my desire to play on the computer (i.e. blogging, open source) and just learn for the next month or so. On my agenda: Spring, WebWork and a Java 1.4 Programmer Certification. 1 month, 2000 pages - if I can restrain my internet addiction, it should be a breeze.

In other news, I'm pumped to see that IDEA is available for $249. My question is - does that give me a license for both a Windows and OS X install?

AppFuse 1.2 Released!

This is primarily a bug fix release. Here are the details from the release notes:

• Backed out Http Post for Remember Me. It was not redirecting user to the page they originally requested. Using reponse.sendRedirect does send the user to the proper location. Turned on password encryption (SHA) to protect any passwords that end up in log files. Turned off encryption in Tomcat.
• Changed configuration parameters in servlet context to be in a hashmap.
• Improvements to StrutsGen tool to generate list screen as well and to fill in more missing elements.
• Changed to close Hibernate session when object not found in BaseDAOHibernate.
• Fixed bug in UserAction.save: when creating a new user, role defaults to "tomcat" regardless of what the user chooses.
• Dependent packages upgraded:
  • Hibernate 2.1.1
  • Struts Menu 2.1
  • WebTest Build 379

Download (~11.9 MB for src, ~4.3 MB for bin) or View Release Notes.

For more information on AppFuse, check out the AppFuse Wiki Page or FAQ.

Struts Menu 2.1 Released!

This release is primarily a bug-fixing release, but I also added a couple of enhancements. The first is the variable substitution now uses JSTL, which means two things.

• You must use a JSP 1.2 container and include the standard tag library in your project for this to work.
• You can now use "dot" notation in your variables. For example, ${user.name} will now work.

Other enhancements include added support for standalone menus in the Explandable List Menu (no items, just a <Menu>) and highlighting of the last menu clicked.

List of Changes (from http://struts-menu.sourceforge.net/changes-report.html):

• Changed dynamic variable feature to use JSTL's ExpressionEvaluator. To substitute request parameters, you must use ${param.paramName}, rather than just ${paramName}.
• Fixed UseMenuDisplayerTag to allow config in menu-config.xml to override the default (as documented).
• Fixed DisplayMenuTag to continue rendering menu items when Action or Forward lookups fail.
• Added support for highlighting the last menu selected in the Expandable Menu.
• Added support for standalone links/menus (no children) to Expandable Menu.
• Added struts-menu.tld to the binary distribution.

A complete CVS changelog can be found at: http://struts-menu.sourceforge.net/changelog-report.html.

Demo: http://raibledesigns.com/struts-menu
Download: http://tinyurl.com/2aq6k

I realize the JSTL stuff could backfire if users are stuck on an old container. Hopefully, you can simply continue using 2.0 if that's your situation.

JSF 1.0 - Proposed Final Draft Spec and Beta Reference Implementation

From Craig McClanahan on the struts-dev mailing list:

I'm pleased to announce that the Proposed Final Draft version of the JavaServer Faces 1.0 Specification, and a corresponding Beta release of the Reference Implementation, is now available at:

http://java.sun.com/j2ee/javaserverfaces/download.html

Please send any feedback and comments strictly about JavaServer Faces to [email protected].

I'm also finishing up an update to the Struts-Faces Integration Library, and will be making it available (via nightly builds) very soon. Feel free to ask any questions about how to use Struts and JavaServer Faces here on the STRUTS-USER list.

Sweet! It's almost time to try JSF in a webapp. I'd love to offer a web layer for AppFuse in JSF. But then again, I'd like to offer WW2 and Tapestry options too. I just need to figure out how to give the developer that option when building. The main problem is it'd probably be a pain in the ass to maintain all 4 implementations. But then again, that's what unit tests are for!

In other news, a nice patch has been proposed for the DisplayTag that would give it JSTL's EL support.

[ANNOUNCE] Ant 1.6 Released!

Big news baby - the best Java tool in the world has a new release. I don't know that I'll use any of the new features (such as antlib, macrodef, presetdef, ssh tasks), but I do love to upgrade. Downloading now...

Later: It looks like Canoo's WebTest is not compatible with Ant 1.6. Reverting back to 1.5.4.

C:\Source\appfuse\test\web\web-tests.xml:29: Task must be of type "Step": invoke at 
C:\Source\appfuse\test\web\login.xml:1:  is of type org.apache.tools.ant.UnknownElement

Line 29 is: <canoo name="login">. I've notified the webtest mailing list, hopefully there will be a resolution shortly.

Struts 2.0

There's a flurry of e-mails about Struts 2.0 dancing around on the Struts Developers Mailing List. Looking at the Overview or the ReadMe, you can see that there's some major (revolutionary) changes being discussed. The Struts Bandwagon is alive and well. The proposal is called Jericho (since it tries to tear-down the walls within the Struts architecture) and proposes to open-up Struts by:

• Declaring interfaces for all core components.
• Providing working base implementations for all core components.
• Encapsulating alll path references within "Location" objects (fka ActionForwards) and referring only to Locations from all other objects.
• Providing additional extension points from core components so that the "Inversion of Control" pattern is fully realized. (e.g., a populate method for the FormHandler.)
• Providing "POJO" signatures that encapsulate servlet/portlet behavior so that applications can be freed of servlet/portlet semantics, if so desired. This strategy would also be applied to optional packages like Validator and Tiles.
• Retain optional access to servlet/portlet objects so that applications can be free to do whatever they need to do.

Also under consideration - adding Struts Menu to the core. Good stuff my friends, good stuff.

Also noticed on the mailing list - Tomcat is not the Servlet/JSP reference implementation (news to me):

There is a (mis)conception, for example, that Tomcat is the RI for the servlet and JSP APIs. That is not the case -- the official RI is the "J2EE SDK" available at http://java.sun.com/j2ee/1.4/download-dr.html. It happens to *include* code from Tomcat, but this is the real RI.