[Glass] WARequestContextNotFound after seaside-flow call:
Jupiter Jones
jupiter.jones at mail.com
Thu May 21 04:54:25 PDT 2020
Hi Andreas,
I use call:onAnswer: a lot and just changed a couple of them to call: just to see… and had the same issue.
Seaside is installed from the main Seaside repo on Github in GemStone 3.5.1.
Without a debugger it’s not easy to pinpoint but a quick look at the log and the various call: methods, it does look like there’s something going on with GRPlatform current seasideSuspendFlowDo:
Had the same issue with #wait: …as would be expected if the issue is in GRPlatform current seasideSuspendFlowDo:
Cheers,
Phil
PS Copied this message to the Seaside list just in case someone there has seen this before.
> On 21 May 2020, at 6:52 pm, Brodbeck Andreas via Glass <glass at lists.gemtalksystems.com> wrote:
>
> Additional astonishing observation: In a plain installation without any code from mine the WAFlowFunctionalTest fails! (GemStone 3.4.5, latest Seaside, latest GsDevKit, Platform Linux)
>
> (I previously reported "all tests green" but that did not include the functional tests ...)
>
> Since this would be a bug at the heart of seaside, I doubt my observations. I will investigate some more.
>
> Cheers, Andreas
>
>> Am 20.05.2020 um 23:01 schrieb Brodbeck Andreas via Glass <glass at lists.gemtalksystems.com <mailto:glass at lists.gemtalksystems.com>>:
>>
>> Hi all
>>
>> I have a stubborn "bug" or other creature which I can not catch after days of trying my best... Before I will eventually file a bug report, may I ask you if this problem sounds familiar to someone?
>>
>> Bug summary:
>> Exception WARequestContextNotFound after seaside's call/answer
>>
>> Steps:
>>
>> 1. I have a seaside application running in GemStone 3.4.5, latest Seaside, latest GsDevKit.
>> 2. From the main seaside UI-component I simply open another seaside component with seaside's call: method.
>> 3. I press the "close" UI-button, which calls seaside's answer method of that component.
>> 4. I get a WARequestContextNotFound exception.
>>
>> My observations:
>>
>> --- Bug DOES NOT show up, if I use call:onAnswer: instead of call:. So it probably narrows down to the usage of GRPlatform current seasideSuspendFlowDo:, since that is what call: is using to suspend the flow with continuations.
>>
>> --- Seaside's error handling will in turn fail itself because it also relies on calling current requestContext itself. Only a simple text based stack is placed on GemStone's ObjectLog. And the browser just shows a simple "Internal Error:"
>>
>> --- WACurrentRequestContext is a WADynamicVariable and as such uses the environment dictionary of the active GsProcess (via something like this: Processor activeProcess environment at: WACurrentRequestContext). With stupid pseudo debugging (since I can't get a real debugger to work) I figured out, that after call:/answer the GsProcess changes and starts with an empty environment, therefore missing the WACurrentRequestContext.
>>
>> --- Seaside tests all green
>>
>>
>> I'm really exhausted. Any clues or similar experiences?
>>
>> Thanks!
>>
>> Cheers, Andreas
>>
>>
>> -----------------------------------------
>> Brot? www.brotrezept.ch <http://www.brotrezept.ch/>!
>>
>> Andreas Brodbeck
>> Software-Macher
>> mindclue GmbH
>> Dipl. El.-Ing. ETH
>>
>> +41 55 622 26 24
>> www.mindclue.ch <http://www.mindclue.ch/>
>> -----------------------------------------
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> https://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> https://lists.gemtalksystems.com/mailman/listinfo/glass
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gemtalksystems.com/mailman/private/glass/attachments/20200521/cc5c2847/attachment-0001.htm>
More information about the Glass
mailing list