previously my osgi app was all running from inside one single large bundle. so i decided to split the different components to their own bundles for various reasons. one of these provides a web-browser based user interface.
so as for every other component i just took this and put it in its own as well. strangely wicket started to report errors like “the page you have requested has expired”. and this only happened on a single page, which was actually a navigation page with just links to other pages. so WTF was wrong? took me plenty of time to figure this out. the navigation page is created with wicket by creating links using wickets objects in the page object. so one of these was referring to a page that had an instance variable that was of a type of a class that was located in another bundle now. so the “the page you have requested has expired” was actually an error of type classnotfoundexception but wicket was just showing this as a page expiration for some strange reason. i had to delete line by line the whole page code to find out which line it was breaking over.
before this i thought it might be the cache, which resulted in having to hack the wicket filter to print out the temp directories where it might put them. which of course returned null (the getattribute thing from servletcontext). so after bunch of googling and finding the wicket filecreatetorfactory or something like this in the wicket api docs, i found out i had to get the standard java temp directory property and check there. sure, there were some files in the C:/Documents/blaablaa directory. deleteing them had no effect.
well, after i found the line that broke it i soon figured i had to import the class for the web ui bundle. after this i kept having similar errors for other pages. this time i was thinking i was smarted and went looking for a debug log for wicket. which, by the way is horribly documented (not at all?). well, plenty of googleing around found that it uses slf4j and kind of reminded me of the problems i had starting with wicket to required the slf4j to be present. finally, configuring the logback to print stuff also for org.apache.wicket at debug level i started getting a log file where all the classnotfoundexceptions were present in stead of the page refresh poopoo. which btw, is hard to note from the console because of all the spam that is printed, rolling the exception away from the screen buffer. well, i configured wicket to produce its own log file in the end. maybe now i will do better in the future with this..
Random experiments in software engineering 