Hey guys,
It’s come up a couple of times recently that we’re on a quite old version of Wicket (1.4 when the latest is 6.5, although that’s not as bad as it might sound since the Wicket project went straight from 1.5 to 6.0.)
In particular, in the recent palette patch 1, it was mentioned that we might be fixing a bug that’s already resolved upstream. (I’m not sure whether this is the case.)
Just to remind everyone of the upgrade status, I started working on this a few months ago and got all of GeoServer to compile with Wicket 1.5, but was stalled out when I ran into some test failures and couldn’t determine what the tests should be doing. (These were in the new security module, meaning that ironically GeoServer’s security code is holding us back from updating to a modern version of the web framework we use.) In the interim since I’ve looked at it, we appear to have added new dependencies on Wicket APIs that have been deprecated or removed (for example, we have a custom RequestEncodingStrategy, when the New Way is to use request mappings 2.) So currently the ‘feature-wicket-upgrade’ branch I’ve been working on does not compile (I did just merge from master, but I haven’t addressed the incompatibilities that were added in the last couple of months.)
Anyway, it would be nice to figure out a way forward. Does anyone care about this besides me? How can we avoid getting more and more entwined with old APIs? Can we set a GeoServer version to target this upgrade for?
–
David Winslow
OpenGeo - http://opengeo.org/