joustlog

I’m starting a WebWork2 application, and it’s going okay, but I’m not happy at all with the URL’s that WebWork (at least, in its default configuration) requires.

I’m using a combination of actions and JSP. Generally, a form submits to an action, which may print something itself (using webwork dispatching) or redirect to a new JSP or action. And so far, the URL’s are very ugly. Some of you might not realize what I mean by ugly URL’s, so I’ve collected a few to show you.

Some ugly URL’s from around the internet:

• https://www.ebank.us.hsbc.com/servlet/com.hsbc.us.ibank.signon.Logon, HSBC Online Banking
• http://javablogs.com/ViewHotBlogEntries.action;jsessionid=NLAECKIJCELB, java.blogs “hot entries” page
• https://java-synaptics.dev.java.net/servlets/ProjectDocumentList?folderID=1893&expandFolder=1893&folderID=0, the file listing for a java.net project’s released files
• http://wiki.opensymphony.com/pages/viewpage.action?pageId=1995, the WebWork wiki page for JSP tags

For those of you who don’t agree that those are “bad URL’s” you might want to read the W3C essay Cool URI’s Don’t Change over and over until you agree.

Anyway, WebWork2 seems to force you to use their URL’s, which must end with .jsp and .action (if you’re using JSP and WW2 actions, of course). This is an implementation detail, of course, which language or framework was used to make the site, and I don’t want these implementation details shown to the whole world, making hard-to-remember URL’s which won’t be around if I switch from JSP to Velocity templates, or from WW to Struts.

So, I’m looking for a library or interceptor or servlet or filter or anything that will let me specify what my URL’s are, and which actual physical URL’s they correspond to. I’d like to have a file in my WEB-INF/ that looked like this:

<app-urls>
  <folder name="admin">
    <url path="new-calendar" action="jsp">newCalendar.jsp</url>
    <url path="new-calendar-submit" action="ww2-action">editCalendar</url>
    <url path="edit-calendar" action="jsp">editCalendar.jsp</url>
    <url path="edit-calendar-submit" action="ww2-action">editCalendar</url>
    <folder-root action="page">admin-index.html</folder>
  </folder>
  <url path="calendars" action="ww2-action">calendarList</url>
  <url path="some-old-url.php" action="redirect">calendars</url>
  <folder-root action="ww2-action">frontPage</folder>
</app-urls>

And these would be the only URL’s that existed on the server for this webapp. So, when someone goes to http://site.com/whateverapp/calendars, the calendarList WebWork2 action will be called. When someone goes to http://site.com/whateverapp/admin/, he or she will be shown the contents of admin-index.html.

If the user tried to go to http://site.com/whateverapp/admin/admin-index.html, however, the user would see a 404 not found.

With a scheme like this, a web application would act more like a Java object, the application, which implements an interface, specified by the URL configuration file. I think it would lead to more reliable results from search engines, more memorable URL’s, and

I don’t have much experience with servlets or Java web servers, so if any of you reading this have ever seen something like this, or if you have any ideas about how it could be implemented, please let me know. Maybe if nothing like this exists, I will write it.

After developing Java applications for years, I’m starting my first ever web application, and I’m not having a good time. I chose WebWork because I like Hani Suleiman’s attitude and WebWork looks cool. I started learning WebWork yesterday, and so far it’s been practically nothing but fighting.

First, I couldn’t get WebWork to run at all, which it turns out was because Velocity was trying to write to /root/avalon.log or something, which it obviously wouldn’t have permission to do, since it’s not root. It’s beside the point that root’s home folder is a ridiculous place to save a log file. Anyway, instead of logging to some kind of standard logging system, Velocity just threw an exception and gave up. I fixed this by turning off Velocity logging.

Second, I couldn’t get validation to work, which it turns out was because WebWork 2.1.1 was shipped with a broken version of XWork, which can’t load validators. I fixed this by downloading XWork 1.0.3, and replacing the jar file in the WEB-INF/lib folder.

Now, I can’t call methods on actions from within JSP. The method in my action is being called, and it is returning a value, but somehow that value doesn’t find its way back to the JSP. I’ve tried about five different ways and syntaxes now, which I’ve found from the documentation and Freenode #webwork and the webwork-dev mailing list, and none of them work.

None of this is helped by the fact that in many cases, WebWork doesn’t throw exceptions that it encounters, it just logs them, or throws an empty RuntimeException and doesn’t use exception chaining.

It’s been 27 hours, minus 8 hours sleeping, minus 2 hours eating, so a total of 17 hours, and I still can’t get a demo page working. I only hope the learning curve is steep and quick, and it won’t be this hard the whole way through.

Some people have started using the oscar.jar OSCAR library I mentioned in a previous post, and it’s going pretty well from what I hear. I figure if people start getting into it, I might javadocument it and add full buddy list support and file transfer and all the things we’ve all come to love. (Currently you can use the buddy list to its fullest, and you can do file transfer, but only by manipulating SNAC commands at the protocol layer, instead of at the big fluffy oscar.jar layer.)

oscar.jar has not been officially released, but anyone who wants it can have it.

I have released version 0.1 of my java-synaptics library, a library which gives Java developers direct access to Synaptics TouchPads and other Synaptics human interface devices.

A kind of cool demo (for people with TouchPads) and more information about the release is available at the project website.

java-synaptics 0.1 is the project’s first public release, and only supports the Windows platform.