[Glass] upgradeSeasideImage with GLASS1 loaded

Hi Dale,

In our application load script, I’m hitting an error when the FastCGI package (FastCGI-dkh.33) is reloaded.

Metacello starts the atomic load and in the screenshot the name is sent to a SymbolDictionary, which yields nil.

Does this ring a bell?

The application load script starts by executing the gsUpgrader>>loadGLASS1 which does not error. The error occurs in the Metacello script that loads the application code and pulls in the Seaside dependencies (hence, the FASTCGI).

I’m heading home now and will pick it up later this evening to analyse this more.

Johan

On 03 Mar 2015, at 22:41, Johan Brichau <[hidden email]> wrote:

Okay. So after executing the upgradeSeasideImage with those parameters I am basically back at GLASS.1.0-beta.9 and I should thus also execute the gsUpgrader scripts [2] to get back to having GLASS1 loaded ?

[2] https://github.com/GsDevKit/gsUpgrader#gsupgrader- 

On 03 Mar 2015, at 22:31, Dale Henrichs via Glass <[hidden email]> wrote:

Johan,

Take a look at the steps outlined in the upgrade article for GemStone 3.2[1]. The basic principles apply to earlier versions as well. For 3.1.0.6, your should be loading GLASS 1.0-beta.9....

You have to basically bootstrap GLASS 1.0-beta.9 into your extent, before you can load baselines, etc. The upgradeSeasideImage script gets GLASS bootstrapped and after GLASS is bootstrapped, you should be able to use the same load scripts you had used for bootstrapping your application code ...

Dale

[1] https://github.com/glassdb/webEditionHome/blob/master/docs/upgrade/upgradeToGemStone3.2.md
On 03/03/2015 12:41 PM, Johan Brichau via Glass wrote:

Hi Dale,

I’m running over the steps to upgrade a 3.1.0.5 image to 3.1.0.6.
This image already has GLASS1 loaded.

The upgradeSeasideImage script is normally set to always load GLASS-1.0-beta.9:

{ 'ConfigurationOfGLASS' . '1.0-beta.9' . #('default') . BootstrapRepositoryDirectory } .

Should I replace this guy with a reference to BaselineOfGLASS ?

I did handle a reference to a github project in this upgrade script before (i.e. Zinc) but that just meant caching the right packages in the local monticello directory for the upgrade.
However, if I understand the upgrade script right, it will reload the base GLASS packages and then require to upgrade to 1.0-beta.9 ? And the GLASS to GLASS1 upgrade did require some specific steps, etc… so is that still correct when GLASS1 was already loaded?

I’m currently going to proceed on a trial upgrade an will report how this goes.

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

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

Dale,

The culprit is that this returns nil 

FSResponderRole sharedPools first name

This should return FCGIConstants.

However, it’s already the case before the upgrade, so this has nothing to do with (this) upgrade.

The shared pool FCGIConstants is present before and after the seaside upgrade.

I do notice the Monticello Package is gone, which is why Metacello is loading that package again in the application load.

Hey Dale,

FSResponderRole sharedPools first name

I don't see where this is on the stack?

That’s just how I got my hands on the sharedPool symboldictionary because I got the same crash browsing the FSResponderRole class using OB in GemTools.

It has a nil name and I fixed that now.

In the screenshot, you can see that that SymbolDictionary is in the `each` variable, which is the receiver of #name.

You can try a patch where you do somehthing like the following before loading your application code:

  FCGIConstants classPool name: #'FCGIConstants'

This should patch the #name .... and hopefully get you going again…

Yes, did that and got going again... to the finish line :)

Thanks for the pointer to the upgrade script!!

When I previously did this upgrade over a year ago, I just followed the steps from the pdf manuals. The script really helps a lot in streamlining!!

There’s a couple of issues I hit and needed to work around:

- after the seaside upgrade script, gemtools login was broken and an error occurred when logging in using topaz. This fixed it:

SystemLoginNotification subscriptions remove: #MetacelloGemStonePlatform.

SystemLoginNotification subscriptions remove: #MetacelloGemStonePlatform.

- [1] seems to give the impression you can load GLASS1 using the loadGLASS1.tpz. This is not the case for Gemstone 3.1 at least. I hit a ‘ConfigurationOfGofer’ load error with that and I had to use the GsUpgrader>>upgradeGLASS1 script.

[1] https://github.com/glassdb/webEditionHome/blob/master/docs/upgrade/upgradeToGemStone3.2.md#6-execute-application-load-topaz-file