Improvements and fixes to WAObjectLog and AJAX Error logging#74
Improvements and fixes to WAObjectLog and AJAX Error logging#74dalehenrich merged 2 commits intoGsDevKit:gs_masterfrom
Conversation
…toneStoneWalkback to later improve WAObjectLog * WAGemStoneStoneWalkback #initializeWithException: now delegates to a new method #initializeWithContext: * WAGemStoneStoneWalkback #currentContextForWalkback now delegates to new #currentContextForContinuation: * Added #stackReportLimit and #logContinuation to WARemoteDebuggingContinuation * Make WARemoteDebuggingWalkbackErrorHandler #open to send logContinuation for ajax requests (ajax requests errors were not being written into the gem log until now).
…tinuations from ObjectLog * Fix WAObjectLog #labels to include the entries with priority 8 (inspect). * Added one more column in the report created in WAObjectLog to include a "debug" link for better debugging continuations. * Added a new WAObjectLogDebuggerWalkback, subclass of WAGemStoneWalkback which doesn't know about exceptions at all but just about a continuation. Specially designed for debugging continuations from ObjectLog.
Improvements and fixes to WAObjectLog and AJAX Error logging
|
Dale, For my app, I am using 3.1.3 and I would really like to have these changes included. I tried these changes in 3.1.3 and they work correct. In fact, now that I think of, I did not try in the very trunk of Seaside,....just the 3.1.3 release. Sorry I should have said that. The question is, can these changes be integrated too in the 3.1.3 branch? or..what is the easiest path for me to get these changes? Thanks in advance. |
|
Yeah that can be arranged ... you say that you are using the 3.1.3 branch, is that gs_master_3.1.3 branch or tag v3.1.3.1? There are only minor differences between the two commits ... presumably necessary baseline changes. I ask because I would prefer to include this bugfix as 3.1.3.2 and tag it as such, and that would mean that it should be based off of the tag and not the branch .... I should mention that the tags are the primary management feature and not branches ... the gs_master branch has a linear progression of tags along it and the gs_master_3.* branches are added when it is necessary to add a patch for that specific tag ... With that said, if you are using the gs_master_3.1.3 branch I can add these changes to the branch and I will tag the commit as 3.1.3.0.1 ... I want every named release tagged ... Does this make sense? |
|
Dale, I am using ConfigurationOfSeaside3 from http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main and from my Configuration I set "project: 'Seaside' with: '3.1.3';". Then inside gemstone it seems the repo that was loaded is github://GsDevKit/Seaside31:v3.1.3-gs/repository So I am not sure what I am using. Is that the gs_master_3.1.1 branch or a release? Thanks in advance, |
|
You are using a fixed tag .... I will have to cogitate a bit on this @jbrichau what are your thoughts ... Dale On 06/04/2015 09:49 AM, marianopeck wrote:
|
|
Well... version 3.1.3 should remain what it is but we can make a new version asap. But if you want the changes before that, you should use github commit tags or just reference the master as @dalehenrich says. |
|
I haven't back ported the fix to 3.1.3, because I wan't sure where it should end up ... now it looks like it should end as 3.1.3.2 (branched off of the 3.1.3.1 tag) and I guess we also need to publish a new ConfigurationOfSeaside3? |
|
Ha wait... do we want to have multiple branches? 3.1.4 is the latest version, so why not 3.1.4.1 ? We can indeed publish a new ConfigurationOf |
|
@marianopeck is requesting that I make the patch to 3.1.3, since that's the version he is using ... I've got a pending checkin for the gs_master (today probably) that we could include in 3.1.4.1 ... The branch is only needed to have a place to put the 3.1.3.1 checkin ... otherwise I agree that we don't use branches ... we use tags and if branches are necessary then so be it ... Also note that @marianopeck is using ConfigurationOfSeaside3 ... which is statically pointing to the 3.1.3 tag ... it pre-dates the ability to use tag matching ... |
|
Hi guys, Thanks for discussing for my best usage. My main concern would be to avoid having to use git since nobody in our team is used to. In other words, what is most important for me, is to be able to continue using ConfigurationOfSeaside3. So what I would like is that whether it is a branch,a tag or whatever, I would like to be able to load this from ConfigurationOfSeaside3. Indeed, I am using 3.1.3 and this is a production app. IF 3.1.4 did not changed much from 3.1.3 in the sense that my app code would continue to work fine without many changes, then I am fine with using 3.1.4.1. Of course...I usually prefer to stay with fixed versions. So if 3.1.4.1 would be a "release" then I would be even much happier. If 3.1.4.1 is a branch and each time I load it I get the very last versions of such a branch,...then ok, I will do it anyway, but I would very much prefer a "release" (fixed). Finally, note that besides the improvements, there are 2 fixes. One for the ObjectLog in presence of entries of priority 8, and then the fact that ajax errors were not written into gem log. So...from MY point of view, a new release with the bugfixes would make sense. |
|
@marianopeck, so for the minimum impact on your app, 3.1.3.2 will be the tag that I should create for you ... 3.1.3.1 was an update to the baseline and 3.1.3.2 will be your two bugfixes .... The final question will be how to update the ConfigurationOfSeaside3 ... it looks like a new version was added to ConfigurationOfSeaside3 for version 3.1.3.1, that points at the 3.1.3.1 tag, so we'll go ahead and update the ConfigurationOfSeaside3 for version 3.1.3.2 when we create the tag ... Will that work for you? |
|
Thanks Dale. That would be awesome for me. Then all I need to do is modify my ConfigurationOf to point to 3.1.3.2. Hope this works too for @jbrichau |
|
BTW, I'm chasing down a packaging/configuration error related to these bugfixes ... in an internal test WAObjectLogDebuggerWalkback is not getting loaded, but the reference from WAObjectLog>>debugContinuation: still exists and that leads to an undefined global and a sent but not implemented ... I'll track this down tomorrow and then we'll be ready to tag 3.1.4.1 and I'll be able to backport the changes to 3.1.3.2 ... |
|
Weird... maybe it;s because of a dependency issue? Since now the tool package (the one that includes WAObjectLogDebuggerWalkback) now depends on the superclass (WAGemStoneWalkback was it?) then it may get loaded before the development package is loaded and hence the problem? |
|
I would say it would be better for @marianopeck to move to 3.1.4, as it has many other bugfixes and it is just a bugfix release. We're making complicated version branches like this.
|
|
Hi @jbrichau |
|
Hey @marianopeck Dale has done a great job recording the changes in the release notes. In addition, you can check the commits between both tags to be absolutely certain. In any case, yes, 3.1.4 is a bugfix release. |
|
Of course, I will always recommend to test an upgrade first in your acceptance environment. |
|
@jbrichau Sure. Let me confirm... are you recommending me to use directly 3.1.4 and we publish my fixes there or are you recommending a new tag/release 3.1.4.1 + ConfigurationOfSeaside3? |
|
I would say a 3.1.4.1 Johan (sent from my mobile)
|
|
My problem is that the package itself is not loaded in my load expression. The method WAObjectLog>>debugContinuation: is one package and the class WAObjectLogDebuggerWalkback is in a package that is not loaded, so I want to look at fixing up the dependencies or maybe adjusting the packaging or ??? |
|
Okay, here's the story ... WAObjectLogDebuggerWalkback is a subclass of WAGemStoneWalkback . WAObjectLogDebuggerWalkback is in Seaside-GemStone-Tools-Production and WAGemStoneWalkback is in Seaside-GemStone-Development. The package Seaside-GemStone-Development requires Seaside-GemStone-Tools-Production so the superclass of WAObjectLogDebuggerWalkback is not present when the package loads ... Basically it means that we need to move WAObjectLogDebuggerWalkback into Seaside-GemStone-Development which should not pose a problem...other than the name ... I think a better name would be WAGemStoneContinuationDebugger .... I don't feel real strongly about this, but when I read the code there is nothing object log related in WAObjectLogDebuggerWalkback other than it is called from the WAObjectLog ... @marianopeck your patch is already on the head of gs_master ... you could temporarily reference gs_master until we've tagged v3.1.4.1 and I'm going to hold off on that until we settle on a new name or keep the old one ... and fix the load order problem ... BTW, this showed up in my internal tests because I'm running the full set of tests against a seaside load ... we've disabled the full tests until Issue #55 and #56 are also fixed ... I mention this mainly to point out that it would have been nice to find this load order issue before merging in the change and we would normally find it except for those issues ... BTW, I am not bumping the priority on fixing those issues but just pointing out that normally we would have found this issue and that no new tests are called for ... |
|
Well, let's see I don't have permissions to commit to PharoExtras (where the gettext config resides), the bugs are not going to be easy to fix without basically wholesale butchery ... the gettext tests are passing even with missing globals and unimplemented messages:( .... I'm tempted to just remove the methods or otherwise hack because there's no way to confirm that my gemstone-specific fixes would work anyway ... |
|
... and who the heck thinks this is code that should be allowed to live: translate: aString toLocale: localeID
| here domain |
here := thisContext sender sender sender methodClass.
domain := TextDomainManager domainForClass: here.
^ self translate: aString toLocale: localeID inDomain: domain
Haha! |
|
@dalehenrich WAGemStoneContinuationDebugger sounds good to me. And it doesn't bother to me to move it to Seaside-GemStone-Development. |
|
Cool!! Thanks @dalehenrich and @jbrichau , I just tried and works perfectly. One little note is that 'WAGemStoneContinuationDebugger' ended up alone in 'Seaside-GemStone-Development' and his friends are in 'Seaside-GemStone-Development-Core' (note the -Core at the end). |
3 participants
No description provided.