Hi, It looks like GenericBaseModel has a reference to a JUnit Description? Maybe you can paste your GenericBaseModel class here?
If that's something you'll have a runtime you shouldn't ignore it if you want to support history (the backbutton). If it's just during testing, you can ignore it if you like. Eelco > ch.qos.mistletoe.wicket.Tree > [object=[Page class = ch.qos.mistletoe.wicket.Tree, id = 4 version = 0]] > org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: > \ > Unable to serialize class: org.junit.runner.Description > Field hierarchy is: > 4 [class=ch.qos.mistletoe.wicket.Tree, path=4] > private java.lang.Object org.apache.wicket.MarkupContainer.children > [class=ch.qos.mistletoe.wicket.DescriptionPanel, path=4:node] > private java.lang.Object org.apache.wicket.MarkupContainer.children > [class=[Ljava.lang.Object;] > java.lang.Object org.apache.wicket.Component.data[3] > [class=ch.qos.mistletoe.wicket.DescriptionPanel$1, path=4:node:payload] > java.lang.Object org.apache.wicket.Component.data > [class=org.apache.wicket.model.util.WildcardListModel] > private java.lang.Object > org.apache.wicket.model.util.GenericBaseModel.object > [class=java.util.ArrayList] > private java.lang.Object > org.apache.wicket.model.util.GenericBaseModel.object[write:1] > [class=org.junit.runner.Description] <----- field that is not serializable > at > org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:346) > [wicket-1.4.2.jar:1.4.2] > at > org.apache.wicket.util.io.SerializableChecker.access$500(SerializableChecker.java:63) > [wicket-1.4.2.jar:1.4.2] > at > org.apache.wicket.util.io.SerializableChecker$1InterceptingObjectOutputStream.replaceObject(SerializableChecker.java:494) > [wicket-1.4.2.jar:1.4.2] > at > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1116) > [na:1.6.0_05] > > By the way, if you are wondering where the [wicket-1.4.2.jar:1.4.2] > suffix comes from, it is automatically generated by logback, log4j's > successor.. > > Anyway, my application handles a complex tree-like structure, with > almost all of the contents non-serializable and outside my control. I > don't think I can use a Loadable Detachable Model, because loading the > tree may take several minutes. > > Can I just ignore the serializable exception? If I don't what are the > risks? > > -- > Ceki Gülcü > Logback: The reliable, generic, fast and flexible logging framework for > Java. > http://logback.qos.ch > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
