The interesting thing is that a bounce of the app reads the new variants without a problem. This seems to indicate to me that there must be some initial 'markup discovery' operation when wicket starts up and only those markup files found during that discovery operation can be loaded, ever.
It is interesting that in development mode changed markups will be detected and the latest markup will be used - this is a development mode feature we definitely need in production so that we can change markup without requiring an app bounce. If wicket can detect changed markup when in development mode there must be some 'flag' or 'switch' that we can turn on to tell wicket to detect new markup as well. How hard would this be to add? Is not looking for new markups a performance based design decision? It's not like wicket would have to poll the markup directories constantly - it only needs to check for the existence of a markup file when requested and only if it's not already found in the cache so a check of the file system would only occur the very first time a new page was requested because then it would not exist in the cache. Further requests would merely return the cached version. I would think that this would have negligible affect on performance. > -----Original Message----- > From: Jay Hogan [mailto:[EMAIL PROTECTED] > Sent: Friday, 29 February 2008 8:23 AM > To: users@wicket.apache.org > Subject: Re: Pickup up new markup without restarting webapp > > Chris, > > Have you looked at subclassing MarkupCache? I'm just a Wicket user so one > of > the devs might want to weigh in but that is where I would start looking. > > http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/marku p/ > MarkupCache.html > > Cheers, > Jay > > On Thu, Feb 28, 2008 at 4:01 PM, Chris Colman > <[EMAIL PROTECTED]> > wrote: > > > > Chris, > > > > > > Generating static markup files is not really the "Wicket way" of doing > > > things. Couldn't you just use multiple panels and dynamically > > add/replace > > > as needed ...create-dynamic-markup-hierarchies-using-panels.html? > > > > The scope of different markup we use involves massive changes to the > > whole page, not just a few panels so this solution won't work well for > > us. > > > > > Or maybe variations will work for you (see > > > http://cwiki.apache.org/WICKET/multiple-markups-per-page.html)? > > > > We do use variations - therein lies the problem: A new variation is > > generated to the file system by the web app but when wicket tries to > > render the page using that new variation the variation's markup will be > > ignored until after we bounce the web app. > > > > > If neither of these fits th bill, you could try using a > > > ReloadingWicketFilter: > > > > > > http://people.apache.org/~tobrien/wicket/apidocs/org/apache/wicket/proto <h > ttp://people.apache.org/%7Etobrien/wicket/apidocs/org/apache/wicket/prot o> > > co > > > l/http/ReloadingWicketFilter.html > > > > Does this solution cause a reloading of the entire web app when a new > > markup is detected? If so, ouch! The markup files can be regenerated > > quite frequently and we can't afford to bounce the whole web app each > > time. > > > > Is there an interface used to provide the markup to wicket for which we > > can provide our own implementation and do the loading and caching of > > markup and checking for new markup ourselves? > > > > > > > > Cheers, > > > Jay > > > On Thu, Feb 28, 2008 at 2:40 PM, Chris Colman > > > <[EMAIL PROTECTED]> > > > wrote: > > > > > > > Is there a wicket mode I can configure in which new markup (eg., new > > > > markup variations) can be picked up at run time without restarting > > the > > > > app? > > > > > > > > In our app we can create/generate new markup at runtime. We don't > > want > > > > to have to force a bounce of the web app for wicket to 'see' this > > new > > > > markup. > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > ============================================ > > > Computer Science: solving today's problems tomorrow. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > ============================================ > Computer Science: solving today's problems tomorrow. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
