For a recent project lead, we decided to create a mock-up of the application, so the prospective Customer would be able to see that we understand their needs.

As I’m not very good at interactive HTML mock-ups I decided to go with Wicket, which seemed to be useful and easy when a friend showed me. The mock-up progressed well, but upon deployment all Hell broke loose.

I chose Wicket, because I hate most web frameworks already, Struts is way to old and twisted for anything proper, I have not found a single open source JSF implementation that works properly, and I had nothing concrete against Wicket yet.

I also wanted to try Maven, since I hate it’s conception so much, it seemed like a good time to try, after all we had two days on our hands, why not waste it properly? I still hate it, but only on principle, otherwise it to me it”s a lot like the apt of java. And my world is Debian based. 🙂

So the mock-up went well. I’ve spent hours figuring out how to do a simple menu that shows selected items with the <wicket:link> feature, with mouseovers. I managed to get it working, to realize it would never work on IE. Then I reimplemented it, then again. Finally I threw it all away and added a JavaScript onload and some brute-force to get it working.

function fireOnLoad() {
  // highlight current menu
  var menuTable = window.document.getElementById('menuTable');
  for (var i=0; i<menuTable.rows[2].cells.length; i++) {
    var curM = menuTable.rows[2].cells[i];
    if(curM.children[1].tagName !='A') {
      var curClassName = curM.className + 'Selected';
      curM.className = curClassName ;
      curM.children[0].style.display='block';
      menuTable.rows[1].cells[i].children[0].style.display='block';
    }
  }
  return true;
}

For the HTML code like

<table id="menuTable" class="menuTable" border="0">
<tbody>
<tr>
<td class="subMenuItemContainer"></td>
</tr>
<tr>
<td class="subMenuPointer">
    <img style="display:none" onclick="window.location.href='../img/submenu.gif';return false;" src="../img/submenu.gif" alt="" /></td>
...</tr>
<tr class="menuItemContainer">
<td class="menuItem" onmouseover="return menuRollOver(this)" onmouseout="return menuRollOut(this)">
<div class="hiddenSubMenu">
<ul class="subMenu">
    <li><a href="../pages/AgencyList">Keresés</a></li>
</ul>
</div>
<a href="../pages/AgencyList">Ügynökségek</a></td>
...</tr>
</tbody></table>

It’s quite ugly, but adequate for the current situation.

After the pages were ready and tested on localhost I decided to move it to our server for presentation. The server runs Debian and has an Apache Tomcat 5.5 running on it for ages. It turned out however, that somehow the project requires Tomcat 6. Not wanting to go over all the project’s config, I went for the server upgrade. The Tomcat had no applications that were to be effected, so it seemed like an easy choice.

Install from apt went smoothly, the application deployed easily. There was a strange problem though.

Every time I clicked a link it either didn’t display any images or it displayed some, or none at all. Refreshing the page always changed something. I suspected, it must be an issue with the Wicket filter, but could not put my hand on it.

Trying to isolate the problem I tried loading a single image from the application. It turned out, that a security exception is thrown every time I try to reload a resource that was previously loaded. Turning of security in Tomcat packaged for Debian did not work out of the box, so I tried to find a solution. I found the page on Java security in Wicket but adding the values on the page just resulted in another error.

I decided to add all rules found on the Wicket WIKI, but that wasn’t enough. So I was adding the rules one-by-one to come up with my version of the security policy for 1.4

grant {
// For substitution of one object for another during serialization
// or deserialization. This is used in ReplaceObjectOutputStream,
// which is used for page versioning (undoing changes).
//permission java.io.SerializablePermission "enableSubstitution";

// For FilePageStore's custom serialization
//permission java.io.SerializablePermission "enableSubclassImplementation";

// For crypted URL functionality (see WebRequestWithCryptedUrl).
//permission java.security.SecurityPermission "insertProvider.SunJCE";

// The following was required to get Wicket, at least the examples, to work at all
permission java.lang.reflect.ReflectPermission
   "suppressAccessChecks";
permission java.lang.RuntimePermission
   "accessClassInPackage.org.apache.tomcat.util.http";
permission java.util.PropertyPermission
   "org.apache.tomcat.util.http.FastHttpDateFormat.CACHE_SIZE",
   "read";
};

As it turned out the problem is gone now. At least until I hit another security restriction.