Tag Archives: wicket

wicket on OSGI + customized webapp url

I posted earlier about getting wicket to run on OSGI using the ServletFilter features of the Apache Felix ExtHttpService. Well, that one was done using the default “/*” filter pattern, that is capturing all requests. While Wicket will nicely pass through anything it does not want to handle, I wanted to put my web based UI under something like “/ui/”, meaning I wanted to capture a pattern like “/ui/*”. So, in order to do this, I set it up as

service.registerFilter(new WebUIWicketFilter(), "/ui/*", props, 0, null);

But this did not really work so nicely. While my filter was invoked (as evidenced by some printouts I put in), Wicket never did anything. After googling around and trying to read the WicketFilter source code, I figure that wicket does some form of url matching to figure out if the request is something that Wicket should process. And “/ui/” did not qualify for some reason. So I got it to work with the following addition

Hashtable<String, String> props = new Hashtable<String, String>();
props.put("applicationClassName", WebUIWicketApplication.class.getName());
props.put("filterMappingUrlPattern", "/ui/*");
try {
service.registerFilter(new WebUIWicketFilter(), "/ui/*", props, 0, null);
} catch (ServletException e) {


And here it is the line

props.put("filterMappingUrlPattern", "/ui/*");

that makes the difference. It seems that this is what causes Wicket to realize that the filter pattern given for Felix is intended to be a match for Wicket. Why is this? Don’t really know but I guess this is some form of standard parameter of the Java Servlet spec that is usually taken from the web.xml or something like that. Since I have no web.xml I need to populate it all myself. Well, that’s what I tell myself so I can move on to the next thing.. As long as it works (today), right?


debugging wicket with multiple osgi modules

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..