[Glass] How to remote debug exceptions caused by seaside rendering?

[Dale Henrichs via Glass]

Oh, I forgot to mention that there are alternate ways to get the stack 
from a process .. if you have tODE installed, you might be able to use 
the code that is used to view/`debug` active processes in the `ps list` 
... I haven't tried this sort of thing with continuations, but a 
continuation is just a GsProcess so it should work ...

Dale

On 04/24/2015 09:40 AM, Dale Henrichs wrote:
> Mariano,
>
> Debugging the ajax calls is a bit problematic because the ajax 
> response is in XML and arbitrary xml (which is what is done for the 
> html debugger) is not an acceptable response ...
>
> Anyway ... I would like to see more of the error stack specifically 
> the first couple of frames of the process.
>
> When the debugger is being opened on an error continuation, we 
> basically `execute` the continuation using #debug as the value. The 
> error handling code inserts code that opens a debugger when the value 
> is #debug and voila the debugger is opened.
>
> In your particular case it LOOKS like the continuation was put into 
> the object log without the special debug code and the error you are 
> getting is the result of `executing` the continuation without the 
> benefit of the proper session handlers wrapped around...
>
> BUT, I need to see the full stack or at the least the bottom of the 
> stack to confirm ...
>
> Finally, could you point me to the code where the ajax handler 
> resides? It's been a while since I've been in that part of the code 
> and frankly I recall that there was a problem with error handling for 
> ajax, but I don't  recall actually doing anything about it ... so a 
> pointer will help ... if I don't find what I think I am looking for:)
>
> Dale
>
> On 04/24/2015 08:45 AM, Mariano Martinez Peck via Glass wrote:
>> Hi guys,
>>
>> I think that at some point this worked for me... but it doesn't 
>> anymore...  I have a seaside app and it is using the 
>> WAGemsToneWalkbackErrorHandler. I have an ajax request  that it seems 
>> to be causing a walkback. Since it is an ajax call, I do not even 
>> receive the walkback page where it shows the stack and I have the 
>> buttons "remote debug", "full stack" , etc. Instead.... I have a new 
>> entry in the Object Log. In other words, in GemTools I go to "Debug" 
>> and I see the exception there. THERE in the list, I can see the real 
>> error..for example "MessageNotUnderstood ocurred (error 2010), a Set 
>> does not undersntand #'on:'".   However, when I click in the 
>> exception so that to open a debugger, the debugger cannot open the 
>> stack because it always fails to get the Seaside context (#session 
>> answers nil and therefore I get another new MNU about this). See 
>> attached screenshot.
>>
>> So... the questions is:
>>
>> 1) In the ideal world, I would like to debug it.
>> 2) If I am not in the ideal world, then at least I would like to see 
>> the stack of the exception. Right now I cannot see ANYTHING... all I 
>> know is Set dnu #on:   so yeah, probably a class I don't have a in 
>> GemStone that is getting a class side #on:
>>
>> Any idea how can I make this to work?
>>
>> ps: I have native code enabled. This is in a CentOS machine. I am 
>> using latest GemStone 3.1 and latest Seaside.
>>
>>
>>
>> -- 
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150424/035c3a3a/attachment.html>