You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Ceki Gulcu <ce...@qos.ch> on 2009/10/09 22:41:58 UTC
SerializableChecker$WicketNotSerializableException:
Hello all,
I have a working wicket application but I see the follwowing output on
my console.
22:28:23.921 ERROR org.apache.wicket.util.lang.Objects - Error serializing
object class \
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: SerializableChecker$WicketNotSerializableException:
Posted by Peter Ertl <pe...@gmx.org>.
suggestion:
load your data and keep it in a cache
use LDM to retrieve the data from the cache (e.g. ehcache) or reload
it if it expired.
Am 10.10.2009 um 19:46 schrieb Igor Vaynberg:
> if you do not need to hold on to the data structure between requests
> then there is no need to keep any references to it in the components
> themselves. pass it into the constructor, create whatever components
> you need to represent it in the ui and throw it away. you may have to
> create wrappers around parts of it for some components, i suppose, but
> you should be able to getaway without keeping a reference to it in
> most cases.
>
> a simplified example may be
>
> class mypanel extends panel {
> public mypanel (string id, nonserializable data) {
> add(new label("name", data.getname()));
> add(new label("author", data.getauthor()));
>
> // instead of using a listview for repeaters use repeatingview
> which lets you construct a repeater without a backing model
> repeatingview rows=new repeatingview();
> add(rows);
> for (change:data.getchanges()) {
> webmarkupcontainer row=new webmarkupcontainer(rows.newchildid
> ());
> rows.add(row);
> row.add(new label("author", change.getauthor());
> row.add(new changesetpanel("changeset", change));
> }
> }
> }
>
>
> -igor
>
> On Sat, Oct 10, 2009 at 9:35 AM, Ceki Gulcu <ce...@qos.ch> wrote:
>>
>>
>> Igor Vaynberg wrote:
>>>
>>> in other words, if you were building this app using jsps or servlets
>>> how would you carry over this data structure between requests?
>>
>> No, I actually would not carry the data between requests. When the
>> page is requested, I would run my test suite to compute the
>> results. Serving the test results from a previous test run is useless
>> and is likely to be misleading..
>>
>> Following Eelco's suggestion, I've set all the fields in my panel
>> (DescriptionPanel) to transient. However, in one case the panel
>> creates a ListView which references non-serializable data items.
>> Thus I
>> started creating a parallel and serializable data class hierarchy for
>> presenting my results, which I am actually quite happy about.
>> However,
>> I also wish I knew a simpler solution if the same question arose in a
>> different context where duplicating the class hierarchy would be
>> inappropriate.
>>
>>> -igor
>>
>> --
>> Ceki Gülcü
>> Logback: The reliable, generic, fast and flexible logging framework
>> for
>> Java.
>> http://logback.qos.ch
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: SerializableChecker$WicketNotSerializableException:
Posted by Igor Vaynberg <ig...@gmail.com>.
if you do not need to hold on to the data structure between requests
then there is no need to keep any references to it in the components
themselves. pass it into the constructor, create whatever components
you need to represent it in the ui and throw it away. you may have to
create wrappers around parts of it for some components, i suppose, but
you should be able to getaway without keeping a reference to it in
most cases.
a simplified example may be
class mypanel extends panel {
public mypanel (string id, nonserializable data) {
add(new label("name", data.getname()));
add(new label("author", data.getauthor()));
// instead of using a listview for repeaters use repeatingview
which lets you construct a repeater without a backing model
repeatingview rows=new repeatingview();
add(rows);
for (change:data.getchanges()) {
webmarkupcontainer row=new webmarkupcontainer(rows.newchildid());
rows.add(row);
row.add(new label("author", change.getauthor());
row.add(new changesetpanel("changeset", change));
}
}
}
-igor
On Sat, Oct 10, 2009 at 9:35 AM, Ceki Gulcu <ce...@qos.ch> wrote:
>
>
> Igor Vaynberg wrote:
>>
>> in other words, if you were building this app using jsps or servlets
>> how would you carry over this data structure between requests?
>
> No, I actually would not carry the data between requests. When the
> page is requested, I would run my test suite to compute the
> results. Serving the test results from a previous test run is useless
> and is likely to be misleading..
>
> Following Eelco's suggestion, I've set all the fields in my panel
> (DescriptionPanel) to transient. However, in one case the panel
> creates a ListView which references non-serializable data items. Thus I
> started creating a parallel and serializable data class hierarchy for
> presenting my results, which I am actually quite happy about. However,
> I also wish I knew a simpler solution if the same question arose in a
> different context where duplicating the class hierarchy would be
> inappropriate.
>
>> -igor
>
> --
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework for
> Java.
> http://logback.qos.ch
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: SerializableChecker$WicketNotSerializableException:
Posted by Ceki Gulcu <ce...@qos.ch>.
Igor Vaynberg wrote:
> in other words, if you were building this app using jsps or servlets
> how would you carry over this data structure between requests?
No, I actually would not carry the data between requests. When the
page is requested, I would run my test suite to compute the
results. Serving the test results from a previous test run is useless
and is likely to be misleading..
Following Eelco's suggestion, I've set all the fields in my panel
(DescriptionPanel) to transient. However, in one case the panel
creates a ListView which references non-serializable data items. Thus I
started creating a parallel and serializable data class hierarchy for
presenting my results, which I am actually quite happy about. However,
I also wish I knew a simpler solution if the same question arose in a
different context where duplicating the class hierarchy would be
inappropriate.
> -igor
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: SerializableChecker$WicketNotSerializableException:
Posted by Igor Vaynberg <ig...@gmail.com>.
in other words, if you were building this app using jsps or servlets
how would you carry over this data structure between requests?
-igor
On Sat, Oct 10, 2009 at 9:09 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> what is the lifecycle of this data? when do you no longer need to store it?
>
> if this is runtime data you can create a runtime store for it, even a
> simple map can do. this map can live in servlet context, spring
> context, as a field of your wicket application, etc. the user pages
> can then retrieve this data without actually having to have a hard
> reference to it. the only trick is knowing when to remove this data
> from memory.
>
> -igor
>
> On Sat, Oct 10, 2009 at 8:39 AM, Ceki Gulcu <ce...@qos.ch> wrote:
>>
>>
>> Igor Vaynberg wrote:
>>>
>>> On Fri, Oct 9, 2009 at 1:41 PM, Ceki Gulcu <ce...@qos.ch> wrote:
>>>>
>>>> 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.
>>>
>>> you would use an LDM per node - the LDM should load the object
>>> represented by that node only, not the entire tree.
>>>
>>> does that make sense?
>>
>> LDM makes sense if you can detach data and then re-attach at a later
>> time. In my case, I can't re-attach data without potentially paying a
>> very severe penalty. (There is no datasource which can be queried for
>> my data, as my data is runtime data. I'd need to re-run tests to
>> re-acquire, which is pretty much nonsensical.)
>>
>>> -igor
>>
>> --
>> Ceki Gülcü
>> Logback: The reliable, generic, fast and flexible logging framework for
>> Java.
>> http://logback.qos.ch
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: SerializableChecker$WicketNotSerializableException:
Posted by Igor Vaynberg <ig...@gmail.com>.
what is the lifecycle of this data? when do you no longer need to store it?
if this is runtime data you can create a runtime store for it, even a
simple map can do. this map can live in servlet context, spring
context, as a field of your wicket application, etc. the user pages
can then retrieve this data without actually having to have a hard
reference to it. the only trick is knowing when to remove this data
from memory.
-igor
On Sat, Oct 10, 2009 at 8:39 AM, Ceki Gulcu <ce...@qos.ch> wrote:
>
>
> Igor Vaynberg wrote:
>>
>> On Fri, Oct 9, 2009 at 1:41 PM, Ceki Gulcu <ce...@qos.ch> wrote:
>>>
>>> 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.
>>
>> you would use an LDM per node - the LDM should load the object
>> represented by that node only, not the entire tree.
>>
>> does that make sense?
>
> LDM makes sense if you can detach data and then re-attach at a later
> time. In my case, I can't re-attach data without potentially paying a
> very severe penalty. (There is no datasource which can be queried for
> my data, as my data is runtime data. I'd need to re-run tests to
> re-acquire, which is pretty much nonsensical.)
>
>> -igor
>
> --
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework for
> Java.
> http://logback.qos.ch
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: SerializableChecker$WicketNotSerializableException:
Posted by Ceki Gulcu <ce...@qos.ch>.
Igor Vaynberg wrote:
> On Fri, Oct 9, 2009 at 1:41 PM, Ceki Gulcu <ce...@qos.ch> wrote:
>> 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.
>
> you would use an LDM per node - the LDM should load the object
> represented by that node only, not the entire tree.
>
> does that make sense?
LDM makes sense if you can detach data and then re-attach at a later
time. In my case, I can't re-attach data without potentially paying a
very severe penalty. (There is no datasource which can be queried for
my data, as my data is runtime data. I'd need to re-run tests to
re-acquire, which is pretty much nonsensical.)
> -igor
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: SerializableChecker$WicketNotSerializableException:
Posted by Igor Vaynberg <ig...@gmail.com>.
On Fri, Oct 9, 2009 at 1:41 PM, Ceki Gulcu <ce...@qos.ch> wrote:
> 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.
you would use an LDM per node - the LDM should load the object
represented by that node only, not the entire tree.
does that make sense?
-igor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: SerializableChecker$WicketNotSerializableException:
Posted by Eelco Hillenius <ee...@gmail.com>.
Btw, this whole serialization problem is exactly why we have
detachable models (though they obviously don't solve every problem out
there. Be sure to read up on those while you're at it.
Eelco
On Fri, Oct 9, 2009 at 3:12 PM, Eelco Hillenius
<ee...@gmail.com> wrote:
> I've looked at it briefly. The main thing you need to keep in mind is
> that it unfortunately is a limitation of Wicket that you can't have
> references in Components that aren't serializable (unless you don't
> care about back button support and turn of the second level session
> cache, OR you plug in your own serialization support that doesn't need
> classes to be serializable).
>
> In this case though, you don't really need those members, right? All
> the members are used in methods that are called during construction of
> the panel, so why not just pass them through those methods (or if you
> don't like that, make the members transient)?
>
> Eelco
>
> On Fri, Oct 9, 2009 at 2:16 PM, Ceki Gulcu <ce...@qos.ch> wrote:
>>
>>
>> Eelco Hillenius wrote:
>>>
>>> Hi,
>>>
>>> It looks like GenericBaseModel has a reference to a JUnit Description?
>>> Maybe you can paste your GenericBaseModel class here?
>>
>> Fortunately, my application is open source. You can find its source code at
>>
>> http://github.com/ceki/mistletoe
>>
>> If you look at the DescriptionPanel class [1] you'll see that it essentially
>> presents a junit.Description and a junit.Failure instance both of which are
>> non-serializable.
>>
>> [1] http://tinyurl.com/yha75x8
>>
>>
>>> 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.
>>
>> My application is a testing platform so I can't ignore junit nor testing.
>> :-)
>>
>> The backbutton, doh! Thanks.
>>
>>> Eelco
>>
>> --
>> Ceki Gülcü
>> Logback: The reliable, generic, fast and flexible logging framework for
>> Java.
>> http://logback.qos.ch
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: SerializableChecker$WicketNotSerializableException:
Posted by Ceki Gulcu <ce...@qos.ch>.
Eelco Hillenius wrote:
> I've looked at it briefly. The main thing you need to keep in mind is
> that it unfortunately is a limitation of Wicket that you can't have
> references in Components that aren't serializable (unless you don't
> care about back button support and turn of the second level session
> cache, OR you plug in your own serialization support that doesn't need
> classes to be serializable).
Thank you for your response. It is much appreciated.
As I understand it, the back button problem is defined as the
undesired triggering of a transaction subsequent to the user going
back and resubmitting. For example, let page C be a purchase
confirmation page and T be the "thank you for your purchase page"
after the user confirms a certain purchase. The user confirms a
purchase on C and the application sends T in response. If the user
clicks on the back button and resubmits C, then the application should
prevent a presumably unwanted re-purchase. Invalidating the cart when
T is sent to the user is sufficient to solve this particular
"back-button" problem.
Again, as I understand it, instead of preserving state, the back-button
problem is addressed by invalidating state. Surely, wicket is
addressing a subtler back-button problem.
> In this case though, you don't really need those members, right? All
> the members are used in methods that are called during construction of
> the panel, so why not just pass them through those methods (or if you
> don't like that, make the members transient)?
Since admittedly I don't actually understand the back-button problem, I
don't see the consequences of eliminating references to unserializable
members in my wicket components. I guess I'll have to experiment.
Alternatively, in the case of this particular problem, I could
construct a parallel serializable class hierarchy. While in the
general case such an approach could be qualified as inelegant or even
dumb, in this particular case it might the cheaper and the more
elegant solution.
Is there a wicket-example illustrating the back-button problem solved
by wicket? I looked at http://wicketstuff.org/wicket14/stateless/ but
its point was lost on me.
> Eelco
>
> On Fri, Oct 9, 2009 at 2:16 PM, Ceki Gulcu <ce...@qos.ch> wrote:
>>
>> Eelco Hillenius wrote:
>>> Hi,
>>>
>>> It looks like GenericBaseModel has a reference to a JUnit Description?
>>> Maybe you can paste your GenericBaseModel class here?
>> Fortunately, my application is open source. You can find its source code at
>>
>> http://github.com/ceki/mistletoe
>>
>> If you look at the DescriptionPanel class [1] you'll see that it essentially
>> presents a junit.Description and a junit.Failure instance both of which are
>> non-serializable.
>>
>> [1] http://tinyurl.com/yha75x8
>>
>>
>>> 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.
>> My application is a testing platform so I can't ignore junit nor testing.
>> :-)
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: SerializableChecker$WicketNotSerializableException:
Posted by Eelco Hillenius <ee...@gmail.com>.
I've looked at it briefly. The main thing you need to keep in mind is
that it unfortunately is a limitation of Wicket that you can't have
references in Components that aren't serializable (unless you don't
care about back button support and turn of the second level session
cache, OR you plug in your own serialization support that doesn't need
classes to be serializable).
In this case though, you don't really need those members, right? All
the members are used in methods that are called during construction of
the panel, so why not just pass them through those methods (or if you
don't like that, make the members transient)?
Eelco
On Fri, Oct 9, 2009 at 2:16 PM, Ceki Gulcu <ce...@qos.ch> wrote:
>
>
> Eelco Hillenius wrote:
>>
>> Hi,
>>
>> It looks like GenericBaseModel has a reference to a JUnit Description?
>> Maybe you can paste your GenericBaseModel class here?
>
> Fortunately, my application is open source. You can find its source code at
>
> http://github.com/ceki/mistletoe
>
> If you look at the DescriptionPanel class [1] you'll see that it essentially
> presents a junit.Description and a junit.Failure instance both of which are
> non-serializable.
>
> [1] http://tinyurl.com/yha75x8
>
>
>> 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.
>
> My application is a testing platform so I can't ignore junit nor testing.
> :-)
>
> The backbutton, doh! Thanks.
>
>> Eelco
>
> --
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework for
> Java.
> http://logback.qos.ch
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: SerializableChecker$WicketNotSerializableException:
Posted by Ceki Gulcu <ce...@qos.ch>.
Eelco Hillenius wrote:
> Hi,
>
> It looks like GenericBaseModel has a reference to a JUnit Description?
> Maybe you can paste your GenericBaseModel class here?
Fortunately, my application is open source. You can find its source code at
http://github.com/ceki/mistletoe
If you look at the DescriptionPanel class [1] you'll see that it essentially
presents a junit.Description and a junit.Failure instance both of which are
non-serializable.
[1] http://tinyurl.com/yha75x8
> 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.
My application is a testing platform so I can't ignore junit nor testing. :-)
The backbutton, doh! Thanks.
> Eelco
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: SerializableChecker$WicketNotSerializableException:
Posted by Eelco Hillenius <ee...@gmail.com>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org