Almost a third of our codebase consists of POJOs generated from Xsd descriptors scattered around in our projects. The generation is performed during build, using a Maven plugin that performs the parsing and generation tasks.

These generated classes are no more than simple value objects descending from a common root object, that contains some well-known methods like toString (), that all methods should share. Unfortunately this particular toString does not know about it’s descendants’ inner structure, so it relies heavily on reflection to perform it’s task. This springs the idea of generating the classes with their own toString methods, so the resulting code is more efficient.

To do this to be backwards compatible, I would have to generate all known xsds, invoke their old and generated toString implementation and compare the results. Also I’d have to fill these objects with values, so I’d have data to compare.

So much for the task, but what’s the fuss about? Well I want the testing kept inside Maven, so should the generated or  inherited code change, we can see it in the build process.

There seem to exist a vast number of ways to be used for mojo testing, starting from the blunt get a mojo instance, fill it with values, and run execute (), to running a separate Maven instance and use the generated test results. Given that in this particular case I’d to start the compiler and then the surefire I (eventually ) went for the later approach.

The plugin testing harness is an example of the earlier approach, while it seems from the usage example the former. Avoid if you have to invoke more, than just your own mojo. It only reads the pom.xml you provide, but doesn’t set up the required Maven environment like builders, project, …etc. It doesn’t do the setup of the default values of your mojo (not that it could resolve the non-existing values for that) So all you end up with is using a helper method for setting up your mojos and executing them from your testcase. I went as far as generating and compiling my classes, but when it came to the point of actually testing them with a surefire mojo I gave up on it, as setting that up would really have been impossible.

I then realized that from testing point of view it is in fact an integration test, not a “mere” unit test, as the testing involves interaction with third party plugins (compiler and surefire) as well. So I converted the package from the plugin testing harness’s structure to the maven-invoker plugin’s recommended structure.  It was nothing more than moving a few directories around, but I could simply throw the complicated mojo invocation out and use a well defined and simple pom instead.  This plugin creates a local repository for itself that contains your project’s dependencies and the artifact to be tested. It’s advised to create a settings.xml that points to your local repository, to limit the unnecessary fetching from your repositories. 

So far, so good. You should keep in mind however, the invoker plugin has some disadvantages. It’s way slower than the harness. It doesn’t aggregate the test results, so all you can see on a failed build, that there were errors in a particular run. Also, since it runs the test in a separate Java environment, you cannot debug your test code, which in my case is quite complex.

So you either create a separate test module and refer to it from the test pom, and create a unit test to test your code with known data, or just be brave write well thought out code and do it properly using log messages to trace your work, just like the good old times. After all repeated failure builds character. 

I actually created a small and a full test environment, testing the particularities of the test separately. To debug the test code you’ve got to import the generated Maven project in your IDE and start the test execution with the local repository and the generated settings.xml.

What were the results? I achieved a speedup of about 90% for completely empty classes, about 70% for classes with data, when the output buffer is limited, and around 30% for classes recursively and completely filled in a depth of four iterations. Overall I could say it’s a 50% improvement on the original method, with a proven backwards compatibility. Considering that this is invoked at least 6 million times a day it might bring a favorable impact on the performance of our systems.

In the process I found 3 errors in the current code, that proved that the output of method’s not used to heavily in the live system. Since the logging it produces is mandatory for regulatory compliance it might just be a good idea to roll it out in the near future.

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.