it seems like a bug in ServletWebRequest#getRelativePathPrefixToWicketHandler(), you might want to subclass that, check for those two params in the url, and add an additional ../.. as a hack for right now.
also open a jira issue for us to fix it. -igor On Wed, Jul 8, 2009 at 2:46 PM, Doug Leeper<[email protected]> wrote: > Our app has been working great this past year but we recently encountered a > strange behavior and wanted to get the communities input on how to proceed. > > Background: > > * Wicket 1.3.6 > * JDK 1.5 > * Jetty (dev) / Apache and Tomcat (prod) > * The URL to our app follows this structure http://mydomain.com/APP > where APP is the web app name. > * We have our img src tags in our HTML utilize relative pathing, i.e. > "images/check.gif". > * Our images are contained in our web app off the root webapp > directory, i.e. "images". > * Some of our pages are bookmarkable utilizing > BookmarkablePageRequestTargetUrlCodingStrategy. > * We have turned on > getPageSettings().setAutomaticMultiWindowSupport(true) in our > Application.init() method > * FireFox 3.5 (is where we are seeing the odd behavior) > The recent change was the bookmarkable pages to produce "pretty URL's" such > as http://localhost:8080/APP/myPage.html. However, we have noticed that in > some cases, i.e. open link in new tab, the bookmarkable page URL changes to > http://localhost:8080/APP/myPage.html/wicket:pageMapName/wicket-1/. The > problem we are having now is that our images are not showing up. Viewing the > source the img src shows "images/check.gif" still. > > > I understand that our URL path has changed and that is why the gif does not > show up. But what is the best approach in handling static images/resources > and with our current configuration. Should we do one or more of the > following? > > > 1. Don't use setAutomaticMultiWindowSupport (we really want this > feature so back button works as expected when new browser tab or window is > opened) > > 2. Use absolute path for images (FYI...we want our war to be a single > deployable unit which includes the images...by doing this, would it require > the static information (images/css/js) to be deployed differently/separately? > 3. Use a different mounted resource strategy? If so, which one? > BTW...no page parameters are needed on the mounted pages in question (they > can be ignored) > > 4. Have all static resources be "wicketized" by using an resource > strategy, i.e. ContextRelativeResource. (this would require a lot of code > changes...not ideal) > 5. Other???Thanks in advance, > - Doug > > BTW...My gut is pointing to #3 is the solution. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
