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 >
