Although the JavaDoc states that this should be possible: // reset for each render in case the strategy is re-used noMoreWicketHeadTagsAllowed = false;
It would be great if we had a failing test-case for this. In my production environment with about 5000 panels, there are none of these issues. Thomas On Thu, Mar 31, 2022 at 10:14 AM Thomas Heigl <tho...@umschalt.com> wrote: > I think we will have to revert WICKET-6963. > > I somehow overlooked the non-final field noMoreWicketHeadTagsAllowed > in AssociatedMarkupSourcingStrategy. If this flag gets set, the singleton > strategy doesn't work. > > Thomas > > On Thu, Mar 31, 2022 at 10:11 AM Thomas Heigl <tho...@umschalt.com> wrote: > >> This is probably caused by my change in >> https://issues.apache.org/jira/browse/WICKET-6963 >> >> I have been using this code in production for a couple of weeks now >> without issues, but there seem to be cases where the singleton strategy >> doesn't work. >> >> Can you reproduce this issue in a test-case? >> >> Thomas >> >> On Thu, Mar 31, 2022 at 10:06 AM Maxim Solodovnik <solomax...@gmail.com> >> wrote: >> >>> "<wicket:head> tags are only allowed before <body>, </head>, >>> <wicket:panel> >>> etc. tag" >>> sounds reasonable :) >>> >>> On Thu, 31 Mar 2022 at 14:56, Korbinian Bachl < >>> korbinian.ba...@whiskyworld.de> wrote: >>> >>> > Hi, >>> > >>> > I deployed our app on 9.9.0 this morning and after initializing a >>> crawl of >>> > the page I ended up getting a low quote of 503s. >>> > >>> > The 503s are always the same: >>> > 2022-03-31 09:35:05,031 ERROR >>> [org.apache.wicket.DefaultExceptionMapper] >>> > Unexpected error occurred >>> > org.apache.wicket.markup.MarkupException: <wicket:head> tags are only >>> > allowed before <body>, </head>, <wicket:panel> etc. tag >>> > at >>> > >>> org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.nextHeaderMarkup(AssociatedMarkupSourcingStrategy.java:341) >>> > ~[wicket-core-9.9.0.jar:9.9.0] >>> > at >>> > >>> org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHeadFromAssociatedMarkupFile(AssociatedMarkupSourcingStrategy.java:236) >>> > ~[wicket-core-9.9.0.jar:9.9.0] >>> > at >>> > >>> org.apache.wicket.markup.html.panel.AssociatedMarkupSourcingStrategy.renderHead(AssociatedMarkupSourcingStrategy.java:204) >>> > ~[wicket-core-9.9.0.jar:9.9.0] >>> > at >>> > org.apache.wicket.Component.internalRenderHead(Component.java:2649) >>> > ~[wicket-core-9.9.0.jar:9.9.0] >>> > .... >>> > at >>> > >>> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:569) >>> > [nucleus-grizzly-all.jar:?] at >>> > >>> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:549) >>> > [nucleus-grizzly-all.jar:?] at java.lang.Thread.run(Thread.java:829) >>> [?:?] >>> > >>> > Any idea how to debug this or where it may come from (race condition in >>> > our code as wicket became faster?)? >>> > It somehow seems to be a happen when requests coming in at the same >>> > time.... with 9.8.0 we got no such errors. >>> > >>> > Best, >>> > >>> > KB >>> > >>> > >>> > >>> > >>> >>> -- >>> Best regards, >>> Maxim >>> >>
