[
https://issues.apache.org/jira/browse/WICKET-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541634
]
Sebastiaan van Erk commented on WICKET-1140:
--------------------------------------------
I looked into providing a patch into this, but it's not entirely trivial.
The problem is that when a MarkupResourceStream is loaded, it is first located
using an IStreamResourceLocator, then it is added to the cache and a watcher so
that changes are noticed. However, what changes in this case is not the
resource itself, but the resource which the locator returns (i.e., after
WebPage.html is added, the locator would now return a resource stream to it,
instead of to the BasePage.html, which is the one it returned before and is
cached).
I can think of several solutions:
1) Push the caching to the locator. I don't like this solution, since the
locator's job should be restricted to locating; make caching one of its
concerns seems like bad separation of concerns. It would also mean quite a
refactor.
2) Ask the locator for the resource every single time to see if it changed it's
mind about the resource. If it returns a different resource from the one in the
cache, cache the new one. The problem with this solution is that it may make
caching pretty useless, as a new resource stream is returned by the localizer
every time anyway...
3) Add a method to the locator to ask if it changed it's mind about the
resource, something like locator.isStillValid(oldResource). The locator should
be able to answer this question, since it is the one responsible for
determining which resource stream to return in the first place. The down side
of this approach is that it is a big API break (it would require all resource
stream locators to implement this new method). As possible means of minimzing
the impact is to have a subinterface of the IStreamResourceLocator interface
implement the new method and use an instanceof check to see if the method
should be called.
I'm not really happy with any of the solutions, though I'm convinced that the
locator has to be involved somehow since it is the ONLY entity which knows if
the resource stream has changed or not. I personally prefer a variant of #3 I
think, but I'm not sure.
I'd like to know your ideas. I don't mind giving it a shot, but I don't want to
start until I have an idea about the preferred approach...
Regards,
Sebastiaan
> Adding WebPage.html after viewing it once requires restart of servlet
> container for updates in developer mode.
> --------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-1140
> URL: https://issues.apache.org/jira/browse/WICKET-1140
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.0-beta4
> Reporter: Sebastiaan van Erk
> Priority: Minor
>
> If you create a WebPage.java (which extends some base page) and view it in
> the browser, and afterwards add WebPage.html and update the browser (in
> development mode), the page will not be updated. The only way to get Wicket
> to see the new WebPage.html file seems to be to restart the servlet
> container. It would be nice if Wicket saw the newly added html file and
> updated the page accordingly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
