[Glass] Install problem

Dale Henrichs dale.henrichs at gemtalksystems.com
Mon Jun 8 14:47:00 PDT 2020


I was able to reproduce your problem ... when I ran my earlier test I 
was using an already cloned version of the project and I wasn't using 
the same project entry.

The  bug was occurring because the project entry that is used to install 
Seaside had the pattern match in it[1] (note the 3.1.?):

    repository: \'github://GsDevKit/Seaside31:3.1.?/repository\'

I replaced the `3.1.? with `v3.1.4.2-gs` and the project loaded 
correctly from that point on. I've patched the project entry[2] up on 
github ...

I recommend that you delete the stone for the failed seaside install and 
run the install script from scratch and let me know if you run into more 
problems ...



On 6/8/20 10:24 AM, Dale Henrichs wrote:

> Gary,
> I just ran a GsDevKit_seaside31/bin/installServerSeaside build that 
> completed successfully, so I'm guessing that my patches to Metacello 
> were sufficient to get past the pattern matching problem you are 
> experiencing ... the pattern matching tests are still failing, but 
> perhaps I was closer than I thought:) ... at this point I will take a 
> closer look at fixing Metacello and I should be able to publish a new 
> version later today.
> Dale
> On 6/8/20 10:00 AM, Dale Henrichs wrote:
>> Gary,
>> This problem showed up about 3 months ago[1][2]. Presumably github, 
>> changed their JSON api. I started work on fixing the problem[3], but 
>> got busy with working on features for the next release of GemStone 
>> and din't finish my work ... IIRC the fix would involve some 
>> additional restructuring of the JSON handling code for GemStone ...
>> The issue revolves around doing pattern matching for releases, which 
>> even when working was pretty dicey, because downloading the list of 
>> tags involves using a rate-limited github api --- pattern matching 
>> has caused persistent build failures for travis builds (exceeding the 
>> rate limit), but has also caused problems with local builds if 
>> several developers are doing Seaside builds or a single developer is 
>> running debugging build problems ...
>> Because of this github rate limit pain, recent versions of Seaside 
>> have removed the version pattern matching from the Metacello spec and 
>> are just using a fixed version.
>> I see that you are using GsDevKit_seaside31[6] and 
>> GsDevKit/Seaside31[7], which is no longer recommended. Seaside3.1 is 
>> a pretty old version of Seaside and is no longer being ported to the 
>> latest versions of GemStone. The GsDevKit_seaside31 project was 
>> created before the main Seaside repository was moved to GitHub, but 
>> now that SeasideSt/Seaside[4] is available, the SeasideSt/Seaside 
>> project is kept up-to-date with the latest versions of GemStone ...
>> If possible you should consider migrating to a newer version of 
>> Seaside and follow these instructions[5] for installing Seaside into 
>> an existing stone. If you are using one of the more recent versions 
>> of Seaside, you will not run into this pattern matching bug...
>> With that said, I understand that it is not a simple matter to just 
>> switch Seaside versions, so I will take some time today to research 
>> the possibility of patching GsDevKit_Seaside31 and GsDevKit/Seaside31 
>> to avoid the pattern matching bug as I think it will be a quicker 
>> route to resolution.
>> Dale
>> [1] https://travis-ci.org/github/Metacello/metacello/builds/655131046
>> [2] https://github.com/Metacello/metacello/issues/514
>> [3] https://github.com/dalehenrich/metacello-work/tree/issue_514
>> [4] https://github.com/SeasideSt/Seaside
>> [5] 
>> https://github.com/GsDevKit/GsDevKit_home/blob/master/docs/gettingStartedWithSeaside.md
>> [6] https://github.com/GsDevKit/GsDevKit_seaside31
>> [7] https://github.com/GsDevKit/Seaside31
>> On 6/8/20 5:36 AM, Gary Chambers via Glass wrote:
>>> Hi all, we seem to have a problem installing Seaside on our server:
>>> when doing
>>>     installServerSeaside -c https -z 8383 seaside_331 3.3.1
>>> we're getting an error with the Metacello handling of <attached 
>>> .json file>.
>>> (see attached output log)
>>> It seems the headers are specified with various upper/lower cases 
>>> (which is fine by the spec: RFC 7230 3.2) but in 
>>> MetacelloGemstonePlatform they are expected to be of a capitalized 
>>> style case. Hence the lookup of 'Status' is failing since the actual 
>>> header specifies 'status'.
>>> Guess this particular JSON response has changed at some point (it's 
>>> been a few years since our last install).
>>> Hope someone can help.
>>> Regards, Gary
>>> _______________________________________________
>>> 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/20200608/ff3380d7/attachment-0001.htm>

More information about the Glass mailing list