>> So, some streamlining might be in order there, even after this particular >> issue. > > Do you have a lot of Ajax updates of small components without > their own markup? > https://issues.apache.org/jira/browse/WICKET-1857 > might be hitting you as well and it would be interesting to > see if your problem still occurs on trunk (or 1.4-RC1).
Not really, I have large chunks (containers.. actually a ListView...). I had a look at the debug output and there is one "DEBUG - MarkupCache - Markup not found: org.apache.wicket.markup.html.form.Formfi_FIhtml" and some "DEBUG - ResourceStreamLocator - Attempting to locate resource 'org/apache/wicket/markup/html/form/Form_fi_FI.html' on" or similar Most of the lines in the debug log consist of: "DEBUG - MarkupContainer - Rendering raw markup" and "DEBUG - Component - Begin render [MarkupContainer [Component id =xx" > The actual parsing results should be cached by IMarkupCache > as far as I know, so if the parsing is really the issue you > could try finding out why is the cache not working (and/or > provide a reproduceable test case in a quickstart). Can you be more specific about this? In what context should the parsing results be cached? You could try ajax-updating a large web page, say having a table with 2000+ rows, and profile it. Do the results look ok for you? I will have a look, but I am not yet very familiar with Wicket internals... the 'what should be''s and nots ** Martin > > -- > Timo Rantalaiho > Reaktor Innovations Oy <URL: http://www.ri.fi/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
