Hi Martin, A quick follow-up:
2. Performance degradation of Wicket tests I just profiled my Wicket tests with Yourkit against 6.21.0 and against 7.2.0. The biggest difference seems to be in MarkupContainer.add(Component[]). It takes 10 times longer on 7.20 than on 6.21.0 It might be related to the issue you mentioned as most of my tests are tests of individual components and panels that are relatively small. Is there something we can do about this? Maybe use a strategy for component adding so that we can switch to the old behavior for tests? Two other methods take up considerable time compared to 6.21.0: - MarkupContainer.getAssociatedMarkup() (5x more) - MarkupContainer.newDequeueContext() (Does not exist in 6.21. and eats up nearly as much time as MarkupContainer.add) I can PM you my profiling results if you are interested. 3. serializer-fast2 throws NullPointerExceptions You were right about the FST version. I only had it pinned in my <dependencyManagement> but no in my <dependencies>. The version used until 6.21.0 (FST 2.10) seems to be the only version that does not throw NPEs in my case. I'll use 2.10 for now and raise the issue with FST. Best regards, Thomas On Mon, Mar 28, 2016 at 2:26 PM, Martin Grigorov <[email protected]> wrote: > Hi, > > On Mon, Mar 28, 2016 at 2:17 PM, Thomas Heigl <[email protected]> wrote: > > > Hi all, > > > > I just finished upgrading a larger application from Wicket 6.21.0 to > Wicket > > 7.2.0. I encountered 3 issues that more or less prevent me from pushing > it > > into production: > > > > 1. There seems to be an issue with <wicket:enclosures/> whose children > are > > added during onConfigure and stateless checking. > > > > Stateless checking triggers visibility checks on the enclosure too early, > > i.e. before the enclosure's children have been added to the page, > resulting > > in exceptions like this: > > > > org.apache.wicket.WicketRuntimeException: Could not find child with id: > > > emptyInfoPanel in the wicket:enclosure > > > > I believe this is fixed in 7.3.0-SNAPSHOT. > Please try it! > > > > > at > > > > > > org.apache.wicket.markup.html.internal.Enclosure.checkChildComponent(Enclosure.java:297) > > > at > > > > > > org.apache.wicket.markup.html.internal.Enclosure.getChildComponent(Enclosure.java:275) > > > at > > > > > > org.apache.wicket.markup.html.internal.Enclosure.getChild(Enclosure.java:138) > > > at > > > > > > org.apache.wicket.markup.html.internal.Enclosure.isVisible(Enclosure.java:173) > > > at org.apache.wicket.Component.determineVisibility(Component.java:4400) > > > at > org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2152) > > > at org.apache.wicket.Component.isStateless(Component.java:2069) > > > at > > > > > > org.apache.wicket.devutils.stateless.StatelessChecker$1.component(StatelessChecker.java:83) > > > at > > > > > > org.apache.wicket.devutils.stateless.StatelessChecker$1.component(StatelessChecker.java:66) > > > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:144) > > > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162) > > > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123) > > > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:192) > > > at > > > > org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:981) > > > at > > > > > > org.apache.wicket.devutils.stateless.StatelessChecker.onBeforeRender(StatelessChecker.java:120) > > > > > > For now, I adjusted my code to add the enclosed components during > > onInitialize. > > > > 2. Performance degradation of Wicket tests > > > > All other things left equal, my 1500 Wicket tests take nearly a minute > > longer to run compared to Wicket 6.21.0. I have not yet had time to > profile > > this. Have there been any configuration changes in WicketTester that > might > > have caused this? > > > > I am not aware of such. > There were some changes in the way Wicket traverses the children of a > container (https://issues.apache.org/jira/browse/WICKET-5983) but it is > slower only for very small pages (less than 10 components in the tree) and > the diff is very small. I am not sure whether this is related. > Wicket 7.x added support for component queueing and this might be the > reason for this case. > > > > > > 3. serializer-fast2 throws NullPointerExceptions > > > > I first encountered this issue when upgrading to Wicket 7.2.0 but later > > discovered that I have the same issue when moving from Wicketstuff 6.21.0 > > to 6.22.0, so I guess this issue was introduced somehow between those > minor > > versions. It has nothing to do with the dependency version of > > de.ruedigermoeller.fst, as I have fixed that to the latest version in my > > POM. > > > > I think we bumped the version of FST recently in wicketstuff-fast2. Could > that be the reason ? > The NPE is in FST code so I'd try to upgrade to latest version and if it > still fails then report it to FST maintainer. > > > > > > > > > Caused by: java.lang.NullPointerException: null > > > at > > > > > > org.nustaq.serialization.FSTObjectOutput.writeObjectWithContext(FSTObjectOutput.java:375) > > > at > > > > > > org.nustaq.serialization.FSTObjectOutput.writeObjectWithContext(FSTObjectOutput.java:361) > > > at > > > > > > org.nustaq.serialization.FSTObjectOutput.writeObjectFields(FSTObjectOutput.java:639) > > > > > > I tried to check the history between those two versions on Github but > > couldn't find any differences. For now, I solved this issue by pinning my > > version of wicketstuff-serializer-fast2 to 6.21.0. > > > > I can try to provide quickstarts for #1 and #3 if needed, altough it > might > > be difficult to extract the behavior from my application. My most > pressing > > issue is #2 as it is the only one I cannot work around and I'm very > > sensitive to build and test feedback time. > > > > Any help would be greatly appreciated. > > > > Best regards, > > > > Thomas > > >
