Hi all, I'm using some wicket:enclosures in the navigation of my web app to hide some content surrounding links, if the links are invisible for some reason. This worked well with Wicket 6.0.x, but now I get the following problem:
Consider a fresh, clean, empty Tomcat server, no wicket persistent data whatsoever, no session, no DiskDataStore, nothing. If I now start my app I can use it without any problems, click links, reload pages, some enclosures are hidden, some are visible, all depending on the visibility of the containing links, everything like I need it. The only thing I'm doing now is restarting the Tomcat server and on refreshing the current page in the browser I get a stackoverflow in Enclosure while trying to determine its visibility. It tries to find its markup, can't, which somehow leads back to where the caller came from in AbstractMarkupSourcingStrategy#searchMarkupInTransparentResolvers and which once again tries to find the markup with the same Enclosure already tried before... The stackoverflow happens in my web app with more complex HTML, but in a reduced version based on a quickstart I don't get one, but instead the following exception is thrown: > java.lang.IllegalArgumentException: Argument 'markup' may not be null. So I guess the root cause is the same in both cases, Enclosure can't find it's markup anymore. Sadly I couldn't reproduce this with Jetty and an original quickstart, because I don't know how to restart Jetty the same way I do with Tomcat. If it gets stopped and started again, it generates a new random temp working dir and starts without persistent data as well, so the problem doesn't occur. Tomcat instead keeps some session data and such during restarts and I guess that's part of the problem. Whenever I clean the working dir of Tomcat, the problem is gone again until I a restart is issued without cleaning the working dir. I tried to track this down and recognized one important difference: On the first empty start of Tomcat without any persistent data, the ids recognized in EnclosureHandler for the tags are different than after a restart of Tomcat. The numeric part of the tag ids is incremented whenever a new tag is recognized and on the first clean start this numeric part is simply higher, e.g. 20, than after a restart, in which case it might be 15. This indicates that after the restart less tags are parsed from the underlying markup compared to the first start of the web app. Because of the wicket page cache and such, the Enclosures with the OLD ids are still assigned to pages after a restart, so if a subsequent process of the markup produces different ids now, Wicket seems unable to find the OLD enclosure ids in the markup, because the MarkupStream now contains Enclosures with NEW ids. I could verify that in the debugger: Wicket tries to determine visibility for Enclosure with id 20, because that was stores in the page cache, and after a restart the logical same markup component now has the id e.g. 15 and therefore can't be found anymore. I think this has to do something with my HTML structure: I have a main div as a WebMarkupContainer, which contains two Panels on the same level, which both contains links. Only second Panel contains the links embedded into enclosures. My feeling is that after a restart the links of the first Panel are not parsed anymore from their markup, because the objects where in the store already, so when the markup for the enclosures in the second panel are parsed, the request unique id is simply less than it was after the first clean start without any persistent data. I have two questions now: 1. Workaround? I think if I'm able to get Wicket to not store any pages anymore persistently, I could workaround the problem. I don't care if people need to login or whatever in the worst case, but the app needs to be functional after a restart of Tomcat without manually cleaning working directories and such. I already tried with a custom DefaultPageManagerProvider and IDataStore implementation which simply doesn't store and retrieve any data. But this is not enough, the problem still occurs. 2. Root cause? In the end of course I need to find the root cause and would like to fix that. How should Wicket behave in parsing markup when pages come from the cache? Does it only parse some missing pieces of markup like for Enclosure, because t doesn't cache it's associated markup/child component or always everything like from a clean start? I guess the first, but that would mean that ids always change and relying on them during subsequent requests is not save. Thanks for any hints! Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org