seaside May 2020

seaside@lists.squeakfoundation.org

4 participants
3 discussions

Re: [Seaside] [Glass] WARequestContextNotFound after seaside-flow call:
by Brodbeck Andreas 21 May '20

21 May '20

> Am 21.05.2020 um 17:32 schrieb Johan Brichau via Glass <glass(a)lists.gemtalksystems.com>: > > 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 ----------------------------------------- Brot? www.brotrezept.ch! Andreas Brodbeck Software-Macher mindclue GmbH Dipl. El.-Ing. ETH +41 55 622 26 24 www.mindclue.ch -----------------------------------------

1 0

Re: [Seaside] [Glass] WARequestContextNotFound after seaside-flow call:
by Jupiter Jones 21 May '20

21 May '20

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(a)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(a)lists.gemtalksystems.com <mailto:glass@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(a)lists.gemtalksystems.com >> https://lists.gemtalksystems.com/mailman/listinfo/glass > > > _______________________________________________ > Glass mailing list > Glass(a)lists.gemtalksystems.com > https://lists.gemtalksystems.com/mailman/listinfo/glass

1 0

ZincStaticServerAdaptor starts with different port
by Esteban Maringolo 10 May '20

10 May '20

Hi, I have a ZnZincStaticServerAdaptor, that after quitting the image and starting it again starts in a different port. So I did: WAServerManager default adaptors do: [ :each | WAServerManager default unregister: each ]. (ZnZincStaticServerAdaptor startOn: 8000 andServeFilesFrom: (FileLocator imageDirectory / 'static' ) asFileReference). And get the server running in the port 8000. [see zn8000.png] But after restarting the image, it is running in the port 80. [see zn80.png] Why is it so? Regards,

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

seaside May 2020