Re: [Glass] WARequestContextNotFound after seaside-flow call:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] WARequestContextNotFound after seaside-flow call:

JupiterJones
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 <[hidden email]> 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 <[hidden email]>:

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!

Andreas Brodbeck
Software-Macher
mindclue GmbH
Dipl. El.-Ing. ETH

+41 55 622 26 24
www.mindclue.ch
-----------------------------------------

_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] WARequestContextNotFound after seaside-flow call:

dassi


Am 21.05.2020 um 17:32 schrieb Johan Brichau via Glass <[hidden email]>:

Andreas,

I now see you wrote that WAFlowFunctionalTest fails in Gemstone.
Will check on that.
The functional tests are not yet running automated in the build (wip), so I need to do that manually and I can tomorrow.

In the meantime, you might want to change WADynamicVariable to be a subclass of GRNotificationBasedDynamicVariable instead of GRDynamicVariable and see if that fixes it?

Yeeeaahhh! That fixes it! Is that workaround safe to use for the moment, so I dont have to downgrade Seaside?

Cheers Andreas



-----------------------------------------

Andreas Brodbeck
Software-Macher
mindclue GmbH
Dipl. El.-Ing. ETH

+41 55 622 26 24
-----------------------------------------


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside