Hi Martin, Thanks for the ultra fast reply!
I believe this is fixed in 7.3.0-SNAPSHOT. > Please try it! I'll give it a try ASAP. 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. I'll do some profiling and report back to you. 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. I'm pretty sure this is not related to FST. I have pinned the version of FST to 2.45 in my POM. It works perfectly with 6.21.0, but throws the NPE with 6.22.0: <dependency> > <groupId>org.wicketstuff</groupId> > <artifactId>wicketstuff-serializer-fast2</artifactId> > <version>6.21.0</version> > </dependency> > <dependency> > <groupId>de.ruedigermoeller</groupId> > <artifactId>fst</artifactId> > <version>2.45</version> > </dependency> I checked https://github.com/wicketstuff/core/compare/wicketstuff-core-6.21.0...wicketstuff-core-6.22.0 but there isn't anything related to serializer-fast except for the FST dependency upgrade. I'll do some more investigating. 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 > > >
