Do you remember where is it? (the blog post)
thanks in advance, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
It was never ported to 3.0 ... so it is in the Seaside2.8 port...
FWIW, I've built a better object log viewer in tODE ... `man ol` for docs ... Dale On 5/29/15 1:40 PM, Mariano Martinez
Peck via Glass wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On Fri, May 29, 2015 at 6:32 PM, Sebastian Heidbrink <[hidden email]> wrote:
Thanks Sebastian. That looks VERY SIMILAR to the tool I saw from Dale. So ... definitively, one based the work in the other :) Not sure who on who hahaha. I just tried it in 3.1.0.6 and seems to work correct. DAle, I also remember using your tool and it also worked for me and I have never worked with gemstone older than 3.0 ... BTW...let me ask something... In my seaside app, I have the remote debug error handler. So if I have an exception that is not cached anyway, I get to the nice seaside walkback with the typical buttons to remote debug, full stack etc. The problem I am having now is if the error happens as part of an ajax callback. In my case, I have an ajax error handler (pasted below). I get the browser popup saying "the program just broke" and everything. But I don't know how I can get the full stack of the error. Imagine the final user using the app. He receives such a popup. Now, me, as developer, how can I see the stacktrace of that error? My gemstone logs show nothing. The user has no way to click or copy paste the stack to send it to me. Thanks in advance (this was the original purpose of why I wanted to explore the object log). ajaxErrorHandler ^ ' if (jqxhr.status == 403) { alert("For security reasons we sign people out during periods of inactivity. Please sign in again."); window.location.href = settings.url.split("?")[0].replace("help",""); } else { // This is on purpose because sometimes with TinyMCE we would get status 0 and empty error...when there was no error // The reason is explained in: http://bartwullems.blogspot.com.ar/2012/02/ajax-request-returns-status-0.html if (jqxhr.readyState == 0 || jqxhr.status == 0) { return; //Skip this error }; // Lets write to console all error info possbile var requestResponse = { url: settings.url, method: settings.type, data: settings.data, httpStatus: jqxhr.status, error: exception || jqxhr.statusText, data: settings.data }; console.error(requestResponse); alert("This program just broke. You can either try again, sign out and sign in and try again, or contact us about error: " + exception); }'
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Haha, now that you mention it, I took a look and found the
component: WAObjectLog. The initialization of the component is
commented out and I presume that that's all you have to do to get it
functioning again.
A google search on WAObjectLog turns up this blog post[1] that has some step by step instructions ... I'll answer your BTW, separately. Dale [1] https://gemstonesoup.wordpress.com/2011/12/02/glass-101-remote-breakpoints-for-seaside-3-0/ On 5/29/15 4:49 PM, Mariano Martinez
Peck via Glass wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Let's see, GsProcess class>>stackReportToLevel: is the message used to dump the error to the gem log and you could add that to the console message. You could also arrange to log the error and stack by arranging to call GRGemStonePlatform>>logError:title:shouldCommit: and the stack would be logged to the gem log and the object log (presumably shouldCommit: should be false as you want to let the final commit before the response is called to do the work)... Then you'd have things covered three ways ... I also thought that the standard continuation error handling logic was triggered by ajax errors and continuations were snapped of for those errors as well ... but I don't see a sender for ajaxErrorHandler in my Seaside image, so perhaps that call is made instead of the call to the standard handler? Dale On 5/29/15 4:49 PM, Mariano Martinez
Peck via Glass wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On Fri, May 29, 2015 at 6:32 PM, Sebastian Heidbrink <[hidden email]> wrote:
Sebastian, While I can get that mcz and it does work for me, I cannot seem to find the repository in ss3. Do you?
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Hi,
WAObjectLog is in the standard Seaside load… you should always have it It is in the Seaside-GemStone-Tools-Production package The repo for Seaside 3.0 is http://seaside.gemtalksystems.com/ss/Seaside30/ Or for Seaside 3.1: https://github.com/GsDevKit/Seaside31 Johan
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Tue, Jun 2, 2015 at 3:00 PM, Johan Brichau via Glass <[hidden email]> wrote:
WTF!!! how could I didn't know about this???? ahahah incredible...it was already loaded in my stone hahahha. Thanks Johan. BTW, I found a bug. It seems that now besides the 7 level of priorities, there is one more: Inspection (GsInspectInteraction). So I had to add 'inspect' to this method: WAObjectLog >> labels ^#('fatal' 'error' 'warn' 'info' 'debug' 'trace' 'transcript' 'inspect'). Because otherwise I would get a LookupFailure in #renderSummaryOn:. Do you agree with the fix? Cheers,
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |