You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jeremy Thomerson <je...@wickettraining.com> on 2009/04/04 19:42:35 UTC
Ideas? SerializableChecker - to flag warning on debug bar
The debug bar that I am working on now can have someone call
addError("MESSAGE") on it, and it will change to a red background color.
When I'm finished, it will also display the errors in an overlay.
I would like the SerializableChecker to be able to signify that there is an
error on the debug bar. But I'm not familiar enough with the serialization
guts to start digging around in there just before a (possibly) final release
candidate. So, what suggestions do you have as to how I can accomplish
this? Basically, I see the following two options thus far:
1. when the SerializableChecker runs, if it encounters an error, it
sticks the error somewhere that is available to the debug bar contributor
1. problem I see: this is probably run way too late
2. another problem: possibly introduces tight coupling
2. the debug bar contributor somehow triggers serialization early or
mimics serialization to see if it is indeed serializable
1. problem: is serializing this early (during render) even valid?
probably not
2. problem: serialization check would be done an extra time.
Any ideas?
--
Jeremy Thomerson
http://www.wickettraining.com
Re: Ideas? SerializableChecker - to flag warning on debug bar
Posted by Martijn Dashorst <ma...@gmail.com>.
At our company we set a session attribute and check for that using an
ajax request. If the flag is set, we redirect to the error page.
Martijn
On Sun, Apr 5, 2009 at 7:16 AM, Eelco Hillenius
<ee...@gmail.com> wrote:
> You'd have to rewrite the guts of SerializableChecker a bit, e.g. to
> send a message to observers rather than just throwing a
> WicketNotSerializableException. A default observer can throw that for
> instance, but you could couple other observers, for instance one that
> calls addError. One problem I expect is that I think these exceptions
> are not necessarily thrown in the same thread , in which case this
> wouldn't be very helpful. Unless you add flash messages (through the
> session, will be displayed next request regardless of the page), but I
> think that would be confusing rather than helpful.
>
> I guess if you rewrite enough you can always do this check in the same
> request, in which case displaying in a bar would be neat. Probably
> best to write that from scratch then (well reusing the checker, but do
> the serializing check e.g. at the end of a request cycle.
>
> Eelco
>
> On Sat, Apr 4, 2009 at 10:42 AM, Jeremy Thomerson
> <je...@wickettraining.com> wrote:
>> The debug bar that I am working on now can have someone call
>> addError("MESSAGE") on it, and it will change to a red background color.
>> When I'm finished, it will also display the errors in an overlay.
>>
>> I would like the SerializableChecker to be able to signify that there is an
>> error on the debug bar. But I'm not familiar enough with the serialization
>> guts to start digging around in there just before a (possibly) final release
>> candidate. So, what suggestions do you have as to how I can accomplish
>> this? Basically, I see the following two options thus far:
>>
>> 1. when the SerializableChecker runs, if it encounters an error, it
>> sticks the error somewhere that is available to the debug bar contributor
>> 1. problem I see: this is probably run way too late
>> 2. another problem: possibly introduces tight coupling
>> 2. the debug bar contributor somehow triggers serialization early or
>> mimics serialization to see if it is indeed serializable
>> 1. problem: is serializing this early (during render) even valid?
>> probably not
>> 2. problem: serialization check would be done an extra time.
>>
>> Any ideas?
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
Re: Ideas? SerializableChecker - to flag warning on debug bar
Posted by Eelco Hillenius <ee...@gmail.com>.
You'd have to rewrite the guts of SerializableChecker a bit, e.g. to
send a message to observers rather than just throwing a
WicketNotSerializableException. A default observer can throw that for
instance, but you could couple other observers, for instance one that
calls addError. One problem I expect is that I think these exceptions
are not necessarily thrown in the same thread , in which case this
wouldn't be very helpful. Unless you add flash messages (through the
session, will be displayed next request regardless of the page), but I
think that would be confusing rather than helpful.
I guess if you rewrite enough you can always do this check in the same
request, in which case displaying in a bar would be neat. Probably
best to write that from scratch then (well reusing the checker, but do
the serializing check e.g. at the end of a request cycle.
Eelco
On Sat, Apr 4, 2009 at 10:42 AM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> The debug bar that I am working on now can have someone call
> addError("MESSAGE") on it, and it will change to a red background color.
> When I'm finished, it will also display the errors in an overlay.
>
> I would like the SerializableChecker to be able to signify that there is an
> error on the debug bar. But I'm not familiar enough with the serialization
> guts to start digging around in there just before a (possibly) final release
> candidate. So, what suggestions do you have as to how I can accomplish
> this? Basically, I see the following two options thus far:
>
> 1. when the SerializableChecker runs, if it encounters an error, it
> sticks the error somewhere that is available to the debug bar contributor
> 1. problem I see: this is probably run way too late
> 2. another problem: possibly introduces tight coupling
> 2. the debug bar contributor somehow triggers serialization early or
> mimics serialization to see if it is indeed serializable
> 1. problem: is serializing this early (during render) even valid?
> probably not
> 2. problem: serialization check would be done an extra time.
>
> Any ideas?
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>