Raible Designs

AppFuse 1.4 Released!

This release involves many changes: re-arranging packages/directories, Spring integration, Remember Me refactorings and I also added iBATIS as a persistence option. I also spent a lot of time going through the tutorials to make sure they are up to date. I've been using AppFuse 1.4 for a few weeks on my current project, and I really do like the way Spring makes it easy to configure Hibernate, Transactions and Interface->Implementation relationships. If you're interested in upgrading your AppFuse 1.x app to use Spring, you can checkout this howto.

I also made the leap and moved the AppFuse project from SourceForge to java.net. This is mainly so I have more control over mailing lists and adding other developers. As of today, CVS files in SourceForge and Java.net are the same - but I'll only be updating Java.net from here on out. I also have released files in both projects, but will only use java.net in the future.

• Download (~11.5 MB for src, ~5.1 MB for bin).
• Release Notes
• Demo

I spent all weekend updating the tutorials and fixing release-related issues. Phew - I'm glad that's over. "So," you ask, "what's next?"

A week of vacation (my sister flies in tomorrow), followed by starting to write Spring Live and creating a Spring MVC option for AppFuse. Oh yeah, I'll also be at SD West in Santa Clara, CA - let me know if you plan on attending.

New Phone?

I just got an interesting SMS message from AT&T:

AT&T Wireless: Sony 
Ericsson and AT&T
Wireless have sent 
you a new T226
phone to replace
your current T68 -
no strings attached.
Questions? Call
800-500-3821.

Wierd eh? Is there something wrong with the T68i? I'll admit that the T226 looks a bit nicer, but when I get a new phone - I'd like to go all out. In other words, I'll be talking to Russ to get his recommendation.

Struts 1.2.0 Test Build Available

From the struts-dev mailing list:

The Struts 1.2.0 Test Build is now available here:

http://www.apache.org/~martinc/struts/v1.2.0/

This is the first Struts build being made available following the same
test-and-release process that has been used successfully by the Tomcat
team for some time. It is *not* an official Apache release.

Once feedback has been collected on the stability and general quality of
this build, a determination will be made as to whether it should be
promoted to Alpha status.

You can reference the Struts site for a list of what's changed since 1.1. To further assist you (if you're upgrading from 1.1), you might want to check out how I did it back in October. I tested this build with AppFuse and all tests pass - I didn't even have to change a single line of code. For that reason, this is now the Struts version that'll ship with AppFuse 1.4.

Supporting OGNL in Tag Libraries

Adding support for JSTL's Expression Language was fairly easy to do in the Display Tag. It was as simple as adding an ExpressionEvaluator and subclassing the ColumnTag and the TableTag. From there, all that was needed was needed a new TLD to reference these new classes.

So the question is - would it be just as easy to support the OGNL Expression Language? Does it have an ExpressionEvaluator I can write with the same simplicity as the JSTL version? If I could figure that out, I think creating OGNL-aware versions of the displaytag and struts-menu would be a piece of cake. All you'd need to do would be to change you're TLD's URI and you'd be off to the races!

How do you get around Struts' single inheritence model?

Adrian Lanning sent me an interesting e-mail yesterday. He's looking for a better way to extend Struts. I thought I'd post his message here and see if anyone has ideas.

I am a big struts fan and use it for my projects but I think there is something fundamentally wrong with the design. The real crux of the matter may be that Java is a single-inheritance model and Struts is designed more for multiple-inheritance.

Example 1.
Complexity when trying to use "extensions" to struts that have their own RequestProcessors. Such as my extension for roles (mentioned below) used together with Asqdotcom's ActionPlugin which is a plugin but still uses its own RequestProcessor, plus another hypothetical extension which has it's own RequestProcessor. Basically the only way to use them all is to modify the source of one or two to extend the others which doesn't seem like a good design.

Example 2.
Extending LookupDispatchAction to include per-method validation (set in struts-config.xml). Basically same problem. Need to combine functionality of ValidatorAction and LookupDispatchAction but can't extend from both. Have to modify source. Actually Brandon Goodin wrote this already (I find it very useful). It's called ValidatorLookupDispatchAction.

I know this is a common issue with single-inheritence models/languages. It would be really easy to extend Struts in a multiple-inheritance model.

* THE POINT *
I was just wondering if you knew of a better way to design when dealing with single-inheritance models to avoid problems such as these.

Personally, I don't find the need to extend Struts that much, so this is not much of an issue for me. I think Struts 2.0 will solve many of Struts single-inheritance design by declaring interfaces for all core components. I wonder when 2.0 is roadmapped to ship - sometime in 2006? ;-)

Later: The article, Security in Struts: User Delegation Made Possible, by Werner Ramaeker provides a good example of a Struts extension strategy.

Upgraded to Tomcat 5.0.19 + thoughts on Resin

I spent 5 minutes tonight and upgraded this site to use Tomcat 5.0.19. Everything seems to be working fine, save for a couple of new messages in catalina.out:

24-Feb-2004 7:48:34 PM org.apache.jk.common.HandlerRequest decodeRequest
WARNING: Error registering request
24-Feb-2004 7:48:44 PM org.apache.jk.common.HandlerRequest invoke
INFO: Unknown message 0

After talking with Rick last weekend, I'm going to try and migrate to Resin as my main dev appserver. The motivating factor was hearing Resin and Orion are so much faster than Tomcat. Sure I've heard this many times before, but mostly from Jakarta-haters. Rick's opinion holds a bit more water for me. Of course, he mentioned that his findings where based on Resin 2.x and Tomcat 4.x. I'd love to see a performance comparison between the latest versions of Orion, Resin and Tomcat.

I hope to modify AppFuse so it can easily run with Tomcat or Resin with a simple property switch. I've already started that process, but I hit a small snag.

I also hope to migrate this site to Resin 3.x soon. If nothing else, it'd be nice to learn more about Resin - and we all know the best way to learn a new technology is to interact with it on a daily basis.

NYC: DisplayTag and Struts Menu

At the NYC Conference, I'm going to be talking about The Display Tag and Struts Menu. I figure the best presentations are ones that cover new features or introduce something new. So I'm hoping to add the following features to the two libraries in the next month. Please let me know if there are other's you'd really like to see - or ones that'd make the audience go *wow*.

DisplayTag: I'd like to add this pagination enhancement so you can get easy interaction between the records displayed and the records fetched. I'd also like to see sorting by property, not be contents. Lastly, I hope to add an example that does CRUD on a table using JSTL and simple checkbox and input fields.

Struts Menu: A lot of users are interested in seeing a menu that's created from a database table. This shouldn't be too difficult because examples are out there. I was also thinking of adding support for the Joust Outliner, but it doesn't look like it's still developer or actively used. If there's interest, I'll add it.

If you think I'm blogging a lot today (don't you work Raible?), it's because I'm on babysitting duty. Abbie is sick with a fever and Julie had to go to work - so my work day starts when she gets home. I've got the little one tied up with a little Winnie the Pooh action right now...

Later: The DHTML Kitchen has some nice menus, but they're not free. Anyone know of open source menus like these?

Whaddya think - comments as wiki pages?

Dan sent me the following in an e-mail and I think he might be onto something:

...what if the comments where organized as
a wiki page themselves (meaning a single wiki page for all comments
to an article)?  This way, the readers could work together to
construct a "follow-up" to the article in an organized,
collaborative manner.

Maybe the problem with comments is the fact that they are linear
(even if threaded) and go on without end.  A wiki would allow some
structure to be established in the comments.  The best part would be
that comments could then have the chance to evolve into core wiki
pages overtime, even though they begin only as a collection of
comments, links and ideas...wait, isn't that what a wiki is anyway?

It sure sounds good. From an implementation perspective, this might be easy to do in Roller with a comment type that uses an <iframe> that points to a JSPWiki installation. A simpler solution might be that users are allowed to edit their own comments. In Roller, we could set a cookie after the user added the comments - allowing them to see an edit/delete link when they return. Whaddya think? Is there a better way for comments to compliment blogs?

While we're talking about comments for blogs - I remember seeing a cool comment-alert system a while back. I can't seem to find it now. If you're spotted a cool alert system you'd like to see in Roller, let me know!

How do you i18n your drop-downs?

As I'm developing this morning and pulling a drop-down list from the database, it hit me - I'm not internationalizing these drop-down values. Sure, putting them in the database makes it easier for admins to edit the values, but if a user visits the site with a Spanish locale, they're going to get English drop-downs. So how do I fix this?

Is the best solution to put the drop-down choices in Struts' ApplicationResources.properties file so that I can render the values with <bean:message/> or <fmt:message/>? How do you do it in your webapps?

In some cases, I guess it doesn't matter as the values need to be in English. Take for instance, AppFuse's edit user screen (user/pass: mraible/tomcat). The list of roles comes from the database and should always be in English because the form-based authentication depends on having an English role_name value in the user_role.role_name column - since this is the value coded in web.xml.

AppFuse 1.3 vs. 1.4

Mike Lawrence (the guy who wrote the AppFuse on Orion tutorial), sent me an e-mail yesterday asking about AppFuse 1.3 (the latest release) vs. 1.4 (still in CVS).

Spring
This looks like a pretty new framework. I wonder how stable it is? 

How far along are you with 1.4? You've made more changes to 1.3 to move
to 1.4 than I've made to 1.3. So, I'd be better off just taking your 1.4
base and integrating my changes.

Did you eliminate struts as the MVC framework?

Doesn't this invalidate your awesome AppFuse tutorials?

I'd really like to stay in sync with your new release, however, I've got
major production deadlines to meet. It would stink if I automated a
bunch of stuff for 1.3 that you couldn't use in 1.4. Yet, if I move to
1.4, will I be facing stability issues and no tutorial docs?

I figured it'd be better if I answer his questions here, as other folks might be wondering the same thing.

Spring - how stable is it?

As with most open source projects, the version number doesn't always indicate the stability of a product. Roller hasn't reached 1.0, but I would venture to say it's a mature and stable product. If you asked this question on the Spring mailing list, you'd likely received a lot of responses saying that it's very stable and used in many production systems. IMO, it's a very stable framework and likely to be the next Struts (in terms of popularity). I don't know that it's MVC framework will be that popular, but it's persistence support classes, declarative transactions and AOP framework are pretty slick. The fact that it integrates smoothly with all leading MVC frameworks is a nice touch too.

I think the best answer is - you need to work with Spring and then decide for yourself. I love writing one-line DAO methods for Hibernate...

How far along are you with 1.4?

If you're already started an application with AppFuse version x, then you should stick with AppFuse version x until your project is finished. It's often a real pain to upgrade an existing app to use the latest stuff, and probably unlikely you'll gain that much value. However, if you're not under a tight deadline - and you really need something in a more recent release - it makes sense to upgrade. The tutorial I wrote on upgrading a 1.3 app to 1.4 is probably a one-time thing. I don't plan to do an upgrade document between all releases.

That being said, if you have enchancements for AppFuse and want me to roll them into the main code base, the best way is to create patches for the CVS version and then it'll be easier for me to figure out what you changed.

Did you eliminate struts as the MVC framework?

Definitely not - Struts will remain as the standard MVC framework because it is the most popular and most AppFuse users will likely use it. When I add MVC alternatives, they will be packaged similar to the iBATIS option - so you'll have to install them. Most MVC options will likely rip out Struts and replace it with their own stuff.

Doesn't this invalidate your awesome AppFuse tutorials?

The tutorials will be updated to support the latest release. I hope to have some time in early March to update these. As soon as I do, I'll release 1.4.

I'd really like to stay in sync with your new release, however, I've got major production deadlines to meet. It would stink if I automated a bunch of stuff for 1.3 that you couldn't use in 1.4. Yet, if I move to 1.4, will I be facing stability issues and no tutorial docs?

Staying in synch with AppFuse as I push out new releases is probably a waste of your time. I did it with Struts Resume for a long time, and it's a lot of work trying to keep up. I firmly believe that each release of AppFuse has been a solid one - they just keep getting better. The only reason to upgrade is for new features and/or bug fixes. I believe that 1.4 will be just as stable as 1.3 and there will be tutorial docs when its released. As far as your automation stuff, the best way to get that added is send me patches against CVS.

BTW, Mike has integrated Middlegen into his AppFuse-based project. He's also working on generating stubs of a lot of the DAO/Manager/Action files - I believe that's his automation stuff. Thanks for giving back so much to AppFuse Mike - now if I only had more time to keep up with your enhancements. ;-)