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.
