It's just a single commit. I have reverted it for both 9.x and master. Best,
Thomas On Thu, Mar 31, 2022 at 11:06 AM Andrea Del Bene <an.delb...@gmail.com> wrote: > On Thu, Mar 31, 2022 at 10:33 AM Thomas Heigl <tho...@umschalt.com> wrote: > > > Ok I had a closer look at AssociatedMarkupSourcingStrategy and the code > > related to this flag is quite convoluted and full of TODOs and WHY > > comments. I think I will have to do another take on this and replace the > > field with a parameter, but this will take some time. > > > > I would suggest we revert WICKET-6963 for now and release 9.9.1. > > > > Sorry for that! I was confident that my change was good, because it > worked > > without problems in our production environment. > > > > > Don't worry, these things happened :-) . Could you take care of reverting > WICKET-6963 on git? Or if it's just a commit I can do it by myself. > > > > Thomas > > > > On Thu, Mar 31, 2022 at 10:18 AM Thomas Heigl <tho...@umschalt.com> > wrote: > > > > > 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 > > >>>> > > >>> > > > > > -- > Andrea Del Bene. > Apache Wicket committer. >
