Raible Designs

Remotely debug your app in Eclipse

Levent Gurses has a nice blog entry on Remote Debugging with Eclipse. I was able to use his instructions a couple months ago to attach to a remote instance of WebLogic (8.1 SP4) to debug an application. The beauty of his instructions is I had it all working in about 5 minutes. Yesterday I realized you could use the settings in *any* application server, and remotely debug it - or at least you should be able to. Today I noticed he added instructions for Tomcat and JBoss. Good stuff - thanks Levent!

Here's the settings you need in your startup script - just in case Levent's blog is down the next time I need this info.

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044

What's the best way to integrate Ajax into a Java webapp?

I received an e-mail over the weekend asking how to integrating Ajax into into the various web frameworks covered in my Java Web Framework Comparison Whitepaper. Below is my reply:

The best thing that I've seen is to use DWR, Prototype and Scriptaculous.
These will work with all web frameworks, and if you're using Spring on the backend -
DWR makes it easy to expose your beans as JavaScript objects.

Also, there's a number of tag library solutions that greatly simplify things:

  http://javawebparts.sf.net
  http://ajaxanywhere.sf.net
  http://ajaxtags.sf.net

I haven't used the first one, but I have used AjaxAnywhere and saw a demo of
AjaxTags from its developers.  They both look like they could be very useful.

For those of you using Ajax in your Java webapps - what's your advice? Do you use these same libraries or other ones?

This post was partially motivated by my desire to reiterate things that are so obvious.

Maven 2's Transitive Dependencies

I spent a few hours this week integrating Maven 2's Ant tasks into Equinox. Here's a things I discovered in the process.

• The JAR you need to include to use the Maven Tasks is quite large, weighing in at a hefty 833K. Regardless, it's easier to include a ~1MB JAR in CVS than it is 10MB of JARs. Equinox (w/o the extras directory) weighs in at 10.2MB before, 1.3MB after.
• The transitive dependencies feature needs to be cleaned up a fair bit. There are a *lot* of unnecessary dependencies downloaded for many libraries. For example, Hibernate downloads a bunch of JBoss JARs and the Display Tag downloads all the various web framework JARs. I found myself excluding almost as many dependencies as I added.
• Using in-line dependencies (where you specify each one in your build.xml) is cleaner and requires less XML (b/c of attributes vs. elements). I went this route at first and it worked well, but to allow greater flexibility (for those who might want to use Maven 2), I ended up creating a pom.xml. 48 lines in build.xml turned into 195 lines in pom.xml.
• The Maven Developer team provides fantastic support - both on the mailing list and IRC. Thanks Brett!
• Maven 2.0 RC was released today.
• I need to figure out a way to "install" the persistence/web framework options in Equinox. The easiest way from a maintenance perspective is to parse pom.xml to add new dependencies. Entity includes might make the project more extensible though - and easier to upgrade.
• Once you have pom.xml in place, it's pretty easy to make the build/test/package process M2 friendly.
• Maven 2 is faster than Ant.

Overall, it was a pretty frustrating experience, with lots of trail-and-error. In the end, I got it all figured out and the only "hack" I had to do was delete servlet-api-2.4.jar after copying dependencies into my WAR. This is b/c Ant is not smart enough to know that dependencies with a "provided" scope shouldn't be copied. I could probably have a 4th dependencies path to solve this, but deleting sounded easier at the time.

I'm not going to check anything in yet b/c I still have to modify all the installers to specify their dependencies. The main advantage I can see in using a download-dependencies feature is easier upgrading of dependencies. It'll also make a lot more sense in AppFuse b/c certain parts of project (i.e. appfuse-dao.jar) can be published as re-usable modules.

In the meantime, if you'd like to try out Equinox with this feature (works with both Maven 2 or Ant), you can integrate it into a CVS version with the following steps:

• In the equinox directory, create a lib directory and download maven-artifact-ant-2.0-dep.jar into it.
• Replace your build.xml with this build.xml (view diff against current).
• Download pom.xml and put it in the equinox directory.
• Delete web/WEB-INF/lib.

That's it! I'm sure some things can be improved - please let me know if you find any issues.

Trackback Spam

Roller seems to have done a pretty good job of suppressing comment spammers. The math question seems to trip up automated scripts and I only get about 1 or 2 spam comments per month. At least, I only see 1 or 2 per month - many get marked as spam and just sit in the database - never to be displayed. However, recently I've started to notice a lot of Trackback spam.

I dive into my "comment" table a few times a week to format comments so they look like their author intended them to look (I never alter wording). In the past couple of weeks, I've noticed a buttload of spam trackbacks (up to 10-20 per day). Here is an example. How do we go about stopping trackback spam? I'm guessing the easiest way is to disable trackbacks.

Jetty vs. Tomcat vs. Resin: A Performance Comparison

This morning, I did some comparisons between Jetty 5.1.5rc1, Tomcat 5.5.9 and Resin 3.0.14 (OS version). I ran AppFuse's "test-canoo" target, which tests all the JSPs using Canoo WebTest. I did this as a Servlet 2.4 application, and had to tweak some stuff in my web.xml to make it work on Jetty and Resin. Nothing big, just stuff that Tomcat let pass through and these servers didn't. One interesting thing to note that Resin requires you to use "http://java.sun.com/jstl/fmt" for JSTL's "fmt" tag URI, while Jetty and Tomcat require "http://java.sun.com/jstl/fmt_rt". This is with Resin's "fast-jstl" turned off - b/c everything blows up if it's turned on (I don't feel like coding my JSTL to Resin's standards, that's why I turn it off).

Below is a list of the average time it took to run "test-canoo" after I ran it once to compile all the JSPs.

• Jetty: 19 seconds
• Tomcat: 19 seconds
• Resin: 29 seconds

In addition, I tested how long it took for each server to startup - including the initialization of AppFuse.

• Jetty: 7 seconds
• Tomcat: 8 seconds
• Resin: 13 seconds

So what does all this mean? A number of things:

• I need to clean up AppFuse's web.xml a bit for 2.4 applications.
• Putting the database connection pool configuration in a Spring context file (vs. JNDI) makes AppFuse much more portable.
• Jetty isn't as fast as Jetty-lovers say it is (or maybe Tomcat just caught up).
• The open source version of Resin is much slower than the other open source servlet containers.
• I should restructure the build.xml to pull out Tomcat stuff and allow users to specify server deployment settings (i.e. in a ${servername}.xml file).
• Orion still doesn't support the Servlet 2.4 or JSP 2.0 specifications.

[ANN] AppFuse 1.8.2 Released

This release is mostly a bug fix release with no new features. It also includes upgrades to Acegi Security and the Spring Framework. Thanks to all the sponsors who have contributed products and free hosting to the AppFuse project.

• Download
• Release Notes
• Learn more about AppFuse

To see how AppFuse works, please see the following demos:

• Demo of Features in Flash
• Struts + Spring + Hibernate
• Spring + iBATIS
• WebWork + Spring + Hibernate
• JSF + Spring + Hibernate
• Tapestry + Spring + Hibernate

Comments and issues can be sent to the mailing list or posted to the AppFuse Issue Tracker.

P.S. I have the Acegi integration done for Remember Me and SSL Switching in another project, so that support should be in CVS sometime next week. Thanks to Justin Spears for his help on this issue.

Wicket is the most widely used Java Web Framework

According to this post, Wicket is the most widely used Java web framework. While I believe his statements are true, IMO it's only true in the context of this guy's post. My guess is that most of the folks that read his post were Wicket users, or somehow the Wicket Team got wind of this and told users to e-mail this guy. The main reason I don't believe that Wicket is the most popular is because it's so new. I do think it's an up and coming framework that may become the most popular, but I don't think it's there yet.

So, to answer this question, I believe that claiming Wicket to be the most widely is Just Good Guerilla PR. To put some numbers behind that, here's some graphs showing mailing list traffic for the various Java web frameworks.

Granted, these are just indicators of the number of users - but I believe they are a good indicator. One interesting note about these stats is that Wicket's mailing list traffic has increased significantly in the past few months. Ironically, here's what one of the Wicket developers had to say about this statistic about a month ago:

... who says having a lists that has a lot of traffic is a good thing? It might just as well be an indication of a too-hard-to-understand framework having insufficient documention.

In the past couple of months, I've spoke in front of 25+ Java developers on 4 different occasions to talk about web frameworks. I've asked those developers which frameworks they've used, or plan on using. Struts is still the most widely used, with WebWork and Tapestry the least used. Surprisingly, JSF seemed to be getting no traction among the the audiences I spoke to. Even more surprising (to me at least) was that the most popular web framework continues to be the in-house framework. The overwhelming majority of the developers I've talked to aren't even using open-source web frameworks.

Struts Ti

I heard about Struts Ti at OSCON, and after googling a bit today, I've discovered a bit more. Here's a bit about the project from Don Brown's proposal on the Struts Developers Mailing List.

Struts Ti is a simplified Model 2 framework for developing webapps which allows the developer better access to the underlying servlet/portlet environment. It serves a niche of web applications that don't want the additional complexity of server-side components and verbose configuration, yet want the structure and controller features of a modern web framework. Struts Ti builds on the directions of Struts 1.x, yet re-implements the framework to provide a clean slate for the next generation of Struts Ti. It aims to combine the simplicity of Ruby on Rails and NanoWeb, the refinement of WebWork 2, the tool-friendly authoring and Page Flow of Beehive, and the lessons learned from Struts 1.x.

The key word for Struts Ti is simplicity. Ideally, Struts Ti should approach Ruby on Rails levels of easy of use, yet scale up to large applications providing a smooth transition to JSF/Shale if desired.

More information can be found at https://www.twdata.org/projects/struts-ti.

[OSCON] Spring MVC vs. WebWork Smackdown

Matthew Porter and I's Spring MVC vs. WebWork Smackdown presentation was a lot of fun this morning. We had a boxing bell (that I got off eBay) and had a good time ragging on the two frameworks. The only surprise was that Matthew actually ran some metrics on the Spring MVC vs. WebWork code in AppFuse and pointed out that the WebWork version required 25% less code than the Spring version. Oh well. The hard part about this presentation for me was trying to defend Spring MVC and saying it's better than WebWork. Matthew obviously felt strongly that WebWork was the better framework, whereas I like them both.

eXtremeTable - another table tag for sorting and paging

From the AppFuse mailing list and the Spring Forums, I learned about eXtremeTable. This JSP Tag looks similar to the Display Tag, except that it includes support for checkboxes and filtering columns out-of-the-box. If you've used this tag, please let me know how it's working for you.