upgrades report

> Today I had some time to do my first upgrade trials on my local
> machine. Since now I had a 2.3.1 installation with on 1.0-beta.7
> upgrade. I scanned all the changelogs and finally the upgrade manual.
> After reading (and thinking :) ) I figured out what to do to upgrade
> the native installation and the image.
>
> As I changed neither the DataCurator password nor the stone name and
> I have a stand installation in /opt/gemstone all I did was:
>
> - unpack 2.4.4.1 archive in /opt/gemstone - copied *.dbf from
> /opt/gemstone/[2.3.1 dir]/seaside/data to /opt/gemstone/[2.4.4
> dir]/seaside/data - set symlink /opt/gemstone/product to the 2.4.4.1
> installation - started netldi and stone - did upgradeImage -s seaside
>  - did upgradeSeasideImage -s seaside
>
> Worked like a charm.
>
> Connecting with my previous client (pharo 1.0, GemTools 1.0-beta.8,
> gciForMacintosh.so 2.3.1) did not work. Replacing the library with
> the one from 2.4.4.1 made this working. But I had the impression that
> trying to connect with a 2.3.1 library made the gems hang. I needed
> to kill -9 the gems, gstack und gdb Processes. After restart of the
> stone everything worked again.
>
> Then I did upgrade to 1.0-beta.8.1 GLASS (from the update... button
> in the GemTools). Worked perfectly although the gemtools client is
> showing "1.0-beta.8.2 workspace".
>
> Then I tried to prepare a pharo 1.1 gemtools client. I started from
> PharoCore 1.1. A good idea is to
>
> - switch off deprecation warnings (Preferences -> Debugging ->
> Deprecation handling -> "Raise a blocking dialog" needs to be
> unchecked) - allow underscore assignment (Preferences  -> Compiler ->
> "Allow underscore as assignment" needs to be checked) as in the
> GemTools package are some underscore assignments which throws syntax
> errors. One being String>>findGemstoneSelector, but there are others.
>
>
> After loading had finished the omni browser was borked. Not even
> opening a system browser worked. After doing an upgrade via
> ConfigurationOfOmniBrowser the system appeared to be normal again.
> Opening OGLauncer worked but spawning a session gave a debugger with
> an error in FFI. It complains about "ExternalAddress>>clone" method
> is missing. As I'm not familar with FFI issues I stopped here in
> proceeding.

>
> So I'm lucky with a GS 2.4.4.1 installation and a pharo 1.0 based
> GemTools client. So far so good. I saw that the upgradeImage and
> upgradeSeasideImage scripts patch quite a few things in the kernel
> classes. I think it reflects changes in the core system and changes
> on dependent components like monticello. Are there good reason why
> this needs to be done via topaz from the commandline? Does it need to
> avoid the usage of monticello etc. for upgrading? I'm asking myself
> how I will manage my image with the multiuser setup. Running the
> upgrade scripts on my online image would only upgrade the DataCurator
> space (if I understand it correct). Do I need to tweak the script to
> log in as a different user and repeat running of the scripts fro
> every user? Or what would be the upgrade scenario for my setup?
>
> Norbert
>
>

> Norbert Hartl wrote:
>> Today I had some time to do my first upgrade trials on my local
>> machine. Since now I had a 2.3.1 installation with on 1.0-beta.7
>> upgrade. I scanned all the changelogs and finally the upgrade manual.
>> After reading (and thinking :) ) I figured out what to do to upgrade
>> the native installation and the image.
>> As I changed neither the DataCurator password nor the stone name and
>> I have a stand installation in /opt/gemstone all I did was:
>> - unpack 2.4.4.1 archive in /opt/gemstone - copied *.dbf from
>> /opt/gemstone/[2.3.1 dir]/seaside/data to /opt/gemstone/[2.4.4
>> dir]/seaside/data - set symlink /opt/gemstone/product to the 2.4.4.1
>> installation - started netldi and stone - did upgradeImage -s seaside
>> - did upgradeSeasideImage -s seaside
>> Worked like a charm.
>> Connecting with my previous client (pharo 1.0, GemTools 1.0-beta.8,
>> gciForMacintosh.so 2.3.1) did not work. Replacing the library with
>> the one from 2.4.4.1 made this working. But I had the impression that
>> trying to connect with a 2.3.1 library made the gems hang. I needed
>> to kill -9 the gems, gstack und gdb Processes. After restart of the
>> stone everything worked again.
>> Then I did upgrade to 1.0-beta.8.1 GLASS (from the update... button
>> in the GemTools). Worked perfectly although the gemtools client is
>> showing "1.0-beta.8.2 workspace".
>> Then I tried to prepare a pharo 1.1 gemtools client. I started from
>> PharoCore 1.1. A good idea is to
>> - switch off deprecation warnings (Preferences -> Debugging ->
>> Deprecation handling -> "Raise a blocking dialog" needs to be
>> unchecked) - allow underscore assignment (Preferences  -> Compiler ->
>> "Allow underscore as assignment" needs to be checked) as in the
>> GemTools package are some underscore assignments which throws syntax
>> errors. One being String>>findGemstoneSelector, but there are others.
>> After loading had finished the omni browser was borked. Not even
>> opening a system browser worked. After doing an upgrade via
>> ConfigurationOfOmniBrowser the system appeared to be normal again.
>> Opening OGLauncer worked but spawning a session gave a debugger with
>> an error in FFI. It complains about "ExternalAddress>>clone" method
>> is missing. As I'm not familar with FFI issues I stopped here in
>> proceeding.
>
> I tried this a couple of days ago and ran into the initial loading issues and figured that I would get around to the GemTools port to Pharo 1.1 at a later date. If there are folks that are hankering for a Pharo 1.1 GemTools speak up ...
>
>> So I'm lucky with a GS 2.4.4.1 installation and a pharo 1.0 based
>> GemTools client. So far so good. I saw that the upgradeImage and
>> upgradeSeasideImage scripts patch quite a few things in the kernel
>> classes. I think it reflects changes in the core system and changes
>> on dependent components like monticello. Are there good reason why
>> this needs to be done via topaz from the commandline? Does it need to
>> avoid the usage of monticello etc. for upgrading? I'm asking myself
>> how I will manage my image with the multiuser setup. Running the
>> upgrade scripts on my online image would only upgrade the DataCurator
>> space (if I understand it correct). Do I need to tweak the script to
>> log in as a different user and repeat running of the scripts fro
>> every user? Or what would be the upgrade scenario for my setup?
>> Norbert
> Norbert,
>
> The upgradeImage script makes sure that the shared base code
> is upgraded correctly (basically removing and recompiling all methods in the system). So the script only needs to be run once per repository.
>
> The upgradeSeasideImage script makes sure that the code that is being managed by Monticello is upgraded correctly ... for an upgrade from 2.3.x, that means that newer versions of some of the mcz files need to be loaded for the code to work correctly in 2.4.4.1. The script needs to be run once per GLASS installation (i.e., those things managed by Monticello).
>
> For users that are not using Monticello, we recommend that the reload all of their code from fileins...patching where necessary for 2.4.x compatibility.
>
> I haven't tried to perform the upgradeSeasideImage from within GemTools, so I'm not sure how far you could get before running into trouble:)

> On 29.07.2010, at 23:58, Dale Henrichs wrote:
>
>> Norbert Hartl wrote:
>>> Today I had some time to do my first upgrade trials on my local
>>> machine. Since now I had a 2.3.1 installation with on 1.0-beta.7
>>> upgrade. I scanned all the changelogs and finally the upgrade
>>> manual. After reading (and thinking :) ) I figured out what to do
>>> to upgrade the native installation and the image. As I changed
>>> neither the DataCurator password nor the stone name and I have a
>>> stand installation in /opt/gemstone all I did was: - unpack
>>> 2.4.4.1 archive in /opt/gemstone - copied *.dbf from
>>> /opt/gemstone/[2.3.1 dir]/seaside/data to /opt/gemstone/[2.4.4
>>> dir]/seaside/data - set symlink /opt/gemstone/product to the
>>> 2.4.4.1 installation - started netldi and stone - did
>>> upgradeImage -s seaside - did upgradeSeasideImage -s seaside
>>> Worked like a charm. Connecting with my previous client (pharo
>>> 1.0, GemTools 1.0-beta.8, gciForMacintosh.so 2.3.1) did not work.
>>> Replacing the library with the one from 2.4.4.1 made this
>>> working. But I had the impression that trying to connect with a
>>> 2.3.1 library made the gems hang. I needed to kill -9 the gems,
>>> gstack und gdb Processes. After restart of the stone everything
>>> worked again. Then I did upgrade to 1.0-beta.8.1 GLASS (from the
>>> update... button in the GemTools). Worked perfectly although the
>>> gemtools client is showing "1.0-beta.8.2 workspace". Then I tried
>>> to prepare a pharo 1.1 gemtools client. I started from PharoCore
>>> 1.1. A good idea is to - switch off deprecation warnings
>>> (Preferences -> Debugging -> Deprecation handling -> "Raise a
>>> blocking dialog" needs to be unchecked) - allow underscore
>>> assignment (Preferences  -> Compiler -> "Allow underscore as
>>> assignment" needs to be checked) as in the GemTools package are
>>> some underscore assignments which throws syntax errors. One being
>>> String>>findGemstoneSelector, but there are others. After loading
>>> had finished the omni browser was borked. Not even opening a
>>> system browser worked. After doing an upgrade via
>>> ConfigurationOfOmniBrowser the system appeared to be normal
>>> again. Opening OGLauncer worked but spawning a session gave a
>>> debugger with an error in FFI. It complains about
>>> "ExternalAddress>>clone" method is missing. As I'm not familar
>>> with FFI issues I stopped here in proceeding.
>> I tried this a couple of days ago and ran into the initial loading
>> issues and figured that I would get around to the GemTools port to
>> Pharo 1.1 at a later date. If there are folks that are hankering
>> for a Pharo 1.1 GemTools speak up ...
>>
>>> So I'm lucky with a GS 2.4.4.1 installation and a pharo 1.0 based
>>>  GemTools client. So far so good. I saw that the upgradeImage and
>>>  upgradeSeasideImage scripts patch quite a few things in the
>>> kernel classes. I think it reflects changes in the core system
>>> and changes on dependent components like monticello. Are there
>>> good reason why this needs to be done via topaz from the
>>> commandline? Does it need to avoid the usage of monticello etc.
>>> for upgrading? I'm asking myself how I will manage my image with
>>> the multiuser setup. Running the upgrade scripts on my online
>>> image would only upgrade the DataCurator space (if I understand
>>> it correct). Do I need to tweak the script to log in as a
>>> different user and repeat running of the scripts fro every user?
>>> Or what would be the upgrade scenario for my setup? Norbert
>> Norbert,
>>
>> The upgradeImage script makes sure that the shared base code is
>> upgraded correctly (basically removing and recompiling all methods
>> in the system). So the script only needs to be run once per
>> repository.
>>
>> The upgradeSeasideImage script makes sure that the code that is
>> being managed by Monticello is upgraded correctly ... for an
>> upgrade from 2.3.x, that means that newer versions of some of the
>> mcz files need to be loaded for the code to work correctly in
>> 2.4.4.1. The script needs to be run once per GLASS installation
>> (i.e., those things managed by Monticello).
>>
>> For users that are not using Monticello, we recommend that the
>> reload all of their code from fileins...patching where necessary
>> for 2.4.x compatibility.
>>
>> I haven't tried to perform the upgradeSeasideImage from within
>> GemTools, so I'm not sure how far you could get before running into
>> trouble:)
>
> I'm not sure I understand this. I have several users in my image and
> I did a complete bootstrap for every user. So is there still some
> code shared between those users? If yes did you mean this shared
> parts? If not than I don't understand at all.

> Norbert Hartl wrote:
>> On 29.07.2010, at 23:58, Dale Henrichs wrote:
>>> Norbert Hartl wrote:
>>>> Today I had some time to do my first upgrade trials on my local machine. Since now I had a 2.3.1 installation with on 1.0-beta.7 upgrade. I scanned all the changelogs and finally the upgrade
>>>> manual. After reading (and thinking :) ) I figured out what to do
>>>> to upgrade the native installation and the image. As I changed
>>>> neither the DataCurator password nor the stone name and I have a
>>>> stand installation in /opt/gemstone all I did was: - unpack
>>>> 2.4.4.1 archive in /opt/gemstone - copied *.dbf from /opt/gemstone/[2.3.1 dir]/seaside/data to /opt/gemstone/[2.4.4 dir]/seaside/data - set symlink /opt/gemstone/product to the
>>>> 2.4.4.1 installation - started netldi and stone - did
>>>> upgradeImage -s seaside - did upgradeSeasideImage -s seaside Worked like a charm. Connecting with my previous client (pharo
>>>> 1.0, GemTools 1.0-beta.8, gciForMacintosh.so 2.3.1) did not work.
>>>> Replacing the library with the one from 2.4.4.1 made this
>>>> working. But I had the impression that trying to connect with a
>>>> 2.3.1 library made the gems hang. I needed to kill -9 the gems,
>>>> gstack und gdb Processes. After restart of the stone everything
>>>> worked again. Then I did upgrade to 1.0-beta.8.1 GLASS (from the
>>>> update... button in the GemTools). Worked perfectly although the
>>>> gemtools client is showing "1.0-beta.8.2 workspace". Then I tried
>>>> to prepare a pharo 1.1 gemtools client. I started from PharoCore
>>>> 1.1. A good idea is to - switch off deprecation warnings
>>>> (Preferences -> Debugging -> Deprecation handling -> "Raise a
>>>> blocking dialog" needs to be unchecked) - allow underscore
>>>> assignment (Preferences  -> Compiler -> "Allow underscore as
>>>> assignment" needs to be checked) as in the GemTools package are
>>>> some underscore assignments which throws syntax errors. One being
>>>> String>>findGemstoneSelector, but there are others. After loading
>>>> had finished the omni browser was borked. Not even opening a
>>>> system browser worked. After doing an upgrade via ConfigurationOfOmniBrowser the system appeared to be normal
>>>> again. Opening OGLauncer worked but spawning a session gave a
>>>> debugger with an error in FFI. It complains about
>>>> "ExternalAddress>>clone" method is missing. As I'm not familar
>>>> with FFI issues I stopped here in proceeding.
>>> I tried this a couple of days ago and ran into the initial loading
>>> issues and figured that I would get around to the GemTools port to
>>> Pharo 1.1 at a later date. If there are folks that are hankering
>>> for a Pharo 1.1 GemTools speak up ...
>>>> So I'm lucky with a GS 2.4.4.1 installation and a pharo 1.0 based
>>>> GemTools client. So far so good. I saw that the upgradeImage and
>>>> upgradeSeasideImage scripts patch quite a few things in the
>>>> kernel classes. I think it reflects changes in the core system
>>>> and changes on dependent components like monticello. Are there
>>>> good reason why this needs to be done via topaz from the
>>>> commandline? Does it need to avoid the usage of monticello etc.
>>>> for upgrading? I'm asking myself how I will manage my image with
>>>> the multiuser setup. Running the upgrade scripts on my online
>>>> image would only upgrade the DataCurator space (if I understand
>>>> it correct). Do I need to tweak the script to log in as a
>>>> different user and repeat running of the scripts fro every user?
>>>> Or what would be the upgrade scenario for my setup? Norbert
>>> Norbert,
>>> The upgradeImage script makes sure that the shared base code is
>>> upgraded correctly (basically removing and recompiling all methods
>>> in the system). So the script only needs to be run once per
>>> repository.
>>> The upgradeSeasideImage script makes sure that the code that is
>>> being managed by Monticello is upgraded correctly ... for an
>>> upgrade from 2.3.x, that means that newer versions of some of the
>>> mcz files need to be loaded for the code to work correctly in
>>> 2.4.4.1. The script needs to be run once per GLASS installation
>>> (i.e., those things managed by Monticello).
>>> For users that are not using Monticello, we recommend that the
>>> reload all of their code from fileins...patching where necessary
>>> for 2.4.x compatibility.
>>> I haven't tried to perform the upgradeSeasideImage from within
>>> GemTools, so I'm not sure how far you could get before running into
>>> trouble:)
>> I'm not sure I understand this. I have several users in my image and
>> I did a complete bootstrap for every user. So is there still some
>> code shared between those users? If yes did you mean this shared
>> parts? If not than I don't understand at all.
>
> The base classes and many of the methods in the base classes are shared amongst multiple users. These classes all live in Globals.
>
> The classes that are rooted in UserGlobals are not shared between users. Using GLASS, extension methods to base classes are not shared between users.
>
> For every user that you did a full bootstrap for, you should run the upgradeSeasideImage script, this script affects UserGlobals (or whichever SymbolDictionary you chose as your bootstrapsymbol dictionary ... UserGlobals is the default).
>
> You only need to run the upgradeImage script (which works on classes in Globals) once.

>
> On 30.07.2010, at 00:44, Dale Henrichs wrote:
>
>> Norbert Hartl wrote:
>>> On 29.07.2010, at 23:58, Dale Henrichs wrote:
>>>> Norbert Hartl wrote:
>>>>> Today I had some time to do my first upgrade trials on my local machine. Since now I had a 2.3.1 installation with on 1.0-beta.7 upgrade. I scanned all the changelogs and finally the upgrade
>>>>> manual. After reading (and thinking :) ) I figured out what to do
>>>>> to upgrade the native installation and the image. As I changed
>>>>> neither the DataCurator password nor the stone name and I have a
>>>>> stand installation in /opt/gemstone all I did was: - unpack
>>>>> 2.4.4.1 archive in /opt/gemstone - copied *.dbf from /opt/gemstone/[2.3.1 dir]/seaside/data to /opt/gemstone/[2.4.4 dir]/seaside/data - set symlink /opt/gemstone/product to the
>>>>> 2.4.4.1 installation - started netldi and stone - did
>>>>> upgradeImage -s seaside - did upgradeSeasideImage -s seaside Worked like a charm. Connecting with my previous client (pharo
>>>>> 1.0, GemTools 1.0-beta.8, gciForMacintosh.so 2.3.1) did not work.
>>>>> Replacing the library with the one from 2.4.4.1 made this
>>>>> working. But I had the impression that trying to connect with a
>>>>> 2.3.1 library made the gems hang. I needed to kill -9 the gems,
>>>>> gstack und gdb Processes. After restart of the stone everything
>>>>> worked again. Then I did upgrade to 1.0-beta.8.1 GLASS (from the
>>>>> update... button in the GemTools). Worked perfectly although the
>>>>> gemtools client is showing "1.0-beta.8.2 workspace". Then I tried
>>>>> to prepare a pharo 1.1 gemtools client. I started from PharoCore
>>>>> 1.1. A good idea is to - switch off deprecation warnings
>>>>> (Preferences -> Debugging -> Deprecation handling -> "Raise a
>>>>> blocking dialog" needs to be unchecked) - allow underscore
>>>>> assignment (Preferences  -> Compiler -> "Allow underscore as
>>>>> assignment" needs to be checked) as in the GemTools package are
>>>>> some underscore assignments which throws syntax errors. One being
>>>>> String>>findGemstoneSelector, but there are others. After loading
>>>>> had finished the omni browser was borked. Not even opening a
>>>>> system browser worked. After doing an upgrade via ConfigurationOfOmniBrowser the system appeared to be normal
>>>>> again. Opening OGLauncer worked but spawning a session gave a
>>>>> debugger with an error in FFI. It complains about
>>>>> "ExternalAddress>>clone" method is missing. As I'm not familar
>>>>> with FFI issues I stopped here in proceeding.
>>>> I tried this a couple of days ago and ran into the initial loading
>>>> issues and figured that I would get around to the GemTools port to
>>>> Pharo 1.1 at a later date. If there are folks that are hankering
>>>> for a Pharo 1.1 GemTools speak up ...
>>>>> So I'm lucky with a GS 2.4.4.1 installation and a pharo 1.0 based
>>>>> GemTools client. So far so good. I saw that the upgradeImage and
>>>>> upgradeSeasideImage scripts patch quite a few things in the
>>>>> kernel classes. I think it reflects changes in the core system
>>>>> and changes on dependent components like monticello. Are there
>>>>> good reason why this needs to be done via topaz from the
>>>>> commandline? Does it need to avoid the usage of monticello etc.
>>>>> for upgrading? I'm asking myself how I will manage my image with
>>>>> the multiuser setup. Running the upgrade scripts on my online
>>>>> image would only upgrade the DataCurator space (if I understand
>>>>> it correct). Do I need to tweak the script to log in as a
>>>>> different user and repeat running of the scripts fro every user?
>>>>> Or what would be the upgrade scenario for my setup? Norbert
>>>> Norbert,
>>>> The upgradeImage script makes sure that the shared base code is
>>>> upgraded correctly (basically removing and recompiling all methods
>>>> in the system). So the script only needs to be run once per
>>>> repository.
>>>> The upgradeSeasideImage script makes sure that the code that is
>>>> being managed by Monticello is upgraded correctly ... for an
>>>> upgrade from 2.3.x, that means that newer versions of some of the
>>>> mcz files need to be loaded for the code to work correctly in
>>>> 2.4.4.1. The script needs to be run once per GLASS installation
>>>> (i.e., those things managed by Monticello).
>>>> For users that are not using Monticello, we recommend that the
>>>> reload all of their code from fileins...patching where necessary
>>>> for 2.4.x compatibility.
>>>> I haven't tried to perform the upgradeSeasideImage from within
>>>> GemTools, so I'm not sure how far you could get before running into
>>>> trouble:)
>>> I'm not sure I understand this. I have several users in my image and
>>> I did a complete bootstrap for every user. So is there still some
>>> code shared between those users? If yes did you mean this shared
>>> parts? If not than I don't understand at all.
>>
>> The base classes and many of the methods in the base classes are shared amongst multiple users. These classes all live in Globals.
>>
>> The classes that are rooted in UserGlobals are not shared between users. Using GLASS, extension methods to base classes are not shared between users.
>>
>> For every user that you did a full bootstrap for, you should run the upgradeSeasideImage script, this script affects UserGlobals (or whichever SymbolDictionary you chose as your bootstrapsymbol dictionary ... UserGlobals is the default).
>>
>> You only need to run the upgradeImage script (which works on classes in Globals) once.
>
> I did that. Ran the upgradeImage for SystemUser. Then I accidentially ran upgradeSeasideImage for SystemUser. After that for any other user. After that I could log into all of my users but not as DataCurator anymore. I thought the upgradeSeasideImage broke something. But I redid everything again without having run the upgradeSeasideImage for SystemUser. But the result stayed the same. I ran upgradeSeasideImage for DataCurator and it didn't help (is there a difference if it is done for SystemUser or DataCurator? ). Then  I bootstrapped DataCurator again for 1.0-beta.4 and ran the upgradeSeasideImage afterwards. With that I could log in but an upgrade to 1.0-beta.8 did not succeed.
>
> I'm still trying.
>
> Norbert

>
> On 30.07.2010, at 18:23, Dale Henrichs wrote:
>
>> Norbert Hartl wrote:
>>
>>> Ok, now I got it runnig with DataCurator. What I did:
>>> - copied extent etc fro 2.3.1 installation to 2.4.4.1 installation
>>> data dir
>>> - startnet && startGemstone
>>> - at this stage I could login in with a 2.4.x gemstone client to the
>>> unaltered image 2.3.1 image on the new 2.4.4 server. The image was
>>> 1.0-beat.6 installed
>>> - running the upgradeImage script worked but after that I couldn't
>>> log in as DataCurator anymore
>>
>> The upgradeImage script has the effect of turning off session methods.
>> With session methods disabled, all of the extension methods that have
>> been added to the base classes are not installed which has the effect
>> of  "disabling" DataCurator logins.
>>
> Ok, that explains something.
>
>>> - I thought that the upgradeSeasideImage script is mostly
>>> recompilation so another bootstrap couldn't harm
>>
>> One of the early steps in the upgradeSeasideImage script is enabling
>> sessions methods ... a step that has to be done in order for being
>> able to complete the upgrade steps for Seaside/GLASS
>>
>>> - bootstrapped DataCurator to 1.0-beta.4
>>
>> This step should be unnecessary. Presumably in the end you end up with
>> the same code installed, but I have never tested doing a bootstrap on
>> top of an existing installation....
>>
>> bootstrapping enables session methods which is one of the critical
>> things that needs to be done for DataCurator.
>>
>>> - ran the upgradeSeasideImage (not 100% sure if I did)
>>
>> if you skip the bootstrap and run the upgradeSeasideImage, this is the
>> point at which you should be able to login using the gemtools client.
>>
> No, that's where everything started. I did upgradeImage followed by a
> upgradeSeasideImage but I couldn't log in as DataCurator afterwards.

>
>>> - logged in with the gemtools client - upgraded to 1.0-beta.6 and got
>>> some errors about gofer. But afterwards it showed '1.0-beta.6 workspace'
>>> - upgraded to 1.0-beta.8. Everything worked fine
>>> - upgraded to 1.0-beta.8.1. Everything worked fine
>>
>> Doing the upgrades are fine, but not technically required to run under
>> 2.4.4.1...the goal of the upgrade scripts is to get your existing
>> application running on 2.4 ...
>>
>>> Now I can log in with a 2.4 client to the 2.4 server with an
>>> 1.0-beta.8.1 workspace. Exactly what I wanted. I could imagine that
>>> my procedure could have caused some new problems. But on the other
>>> hand I think that every package has been overriden and it should be
>>> ok. If I didn't do the upgradeSeasideImage (I closed my editor
>>> accidentially where I scribbled my notes) is there something
>>> important I would be missing by now? Can I check somehow?
>>
>> You might take a look at the ObjectLog. In the current version all
>> transcript messages are stashed in the ObjectLog and most of the
>> output during upgrade is done using Transcrip show:, however, I don't
>> recall at which point the recording of the transcript output was
>> implemented ... moving forward it is very convenient to look in the
>> object log to see just what's been going on:)
>>
>>> After that I upgraded all my other users and that worked great. I'll
>>> start to upgrade one of the users to 1.0-beta.8.1 and then I'll try
>>> to start the web gems again. If I get into trouble I'll write another
>>> mail.
>>
>> I'm glad that you are making good progress.
>
> Well, sort of. I managed to upgrade all users so far to 2.4.4 plus
> 1.0-beta.8.1. Installing pier2 in one turn did not succeed. Choosing a
> couple of smaller steps worked.
>
> Next, starting seaside was easy for the users with 2.8 because the
> scripts didn't change. For seaside 3.0 it did't went that easy. The
> script (runSeasideGems30) is somewhat broken. Someone started to change
> to script so you can specify the web adaptor and the port. But the
> script seems only halway done. Checks are for $1 as port at the
> beginning but at the end $2 ist used to start the adaptor. The $1 as
> adaptor reflects only in the printing stuff :) A
>
> runSeasideGems30 "" port
>
> is needed to get it going. Then seaside worked.

> Norbert Hartl wrote:
>> On 30.07.2010, at 18:23, Dale Henrichs wrote:
>>> Norbert Hartl wrote:
>>>
>>>> Ok, now I got it runnig with DataCurator. What I did:
>>>> - copied extent etc fro 2.3.1 installation to 2.4.4.1 installation data dir
>>>> - startnet && startGemstone
>>>> - at this stage I could login in with a 2.4.x gemstone client to the unaltered image 2.3.1 image on the new 2.4.4 server. The image was 1.0-beat.6 installed
>>>> - running the upgradeImage script worked but after that I couldn't log in as DataCurator anymore
>>>
>>> The upgradeImage script has the effect of turning off session methods. With session methods disabled, all of the extension methods that have been added to the base classes are not installed which has the effect of  "disabling" DataCurator logins.
>>>
>> Ok, that explains something.
>>>> - I thought that the upgradeSeasideImage script is mostly recompilation so another bootstrap couldn't harm
>>>
>>> One of the early steps in the upgradeSeasideImage script is enabling sessions methods ... a step that has to be done in order for being able to complete the upgrade steps for Seaside/GLASS
>>>
>>>> - bootstrapped DataCurator to 1.0-beta.4
>>>
>>> This step should be unnecessary. Presumably in the end you end up with the same code installed, but I have never tested doing a bootstrap on top of an existing installation....
>>>
>>> bootstrapping enables session methods which is one of the critical things that needs to be done for DataCurator.
>>>
>>>> - ran the upgradeSeasideImage (not 100% sure if I did)
>>>
>>> if you skip the bootstrap and run the upgradeSeasideImage, this is the point at which you should be able to login using the gemtools client.
>>>
>> No, that's where everything started. I did upgradeImage followed by a upgradeSeasideImage but I couldn't log in as DataCurator afterwards.
>
>
> I would be very interested in the error message that you are getting, because that is the scenario that I did test and I didn't have trouble??
>
> Have you set up DataCurator to use a different SymbolDictionary other than UserGlobals?
>

>
>>>> - logged in with the gemtools client - upgraded to 1.0-beta.6 and got some errors about gofer. But afterwards it showed '1.0-beta.6 workspace'
>>>> - upgraded to 1.0-beta.8. Everything worked fine
>>>> - upgraded to 1.0-beta.8.1. Everything worked fine
>>>
>>> Doing the upgrades are fine, but not technically required to run under 2.4.4.1...the goal of the upgrade scripts is to get your existing application running on 2.4 ...
>>>
>>>> Now I can log in with a 2.4 client to the 2.4 server with an 1.0-beta.8.1 workspace. Exactly what I wanted. I could imagine that my procedure could have caused some new problems. But on the other hand I think that every package has been overriden and it should be ok. If I didn't do the upgradeSeasideImage (I closed my editor accidentially where I scribbled my notes) is there something important I would be missing by now? Can I check somehow?
>>>
>>> You might take a look at the ObjectLog. In the current version all transcript messages are stashed in the ObjectLog and most of the output during upgrade is done using Transcrip show:, however, I don't recall at which point the recording of the transcript output was implemented ... moving forward it is very convenient to look in the object log to see just what's been going on:)
>>>
>>>> After that I upgraded all my other users and that worked great. I'll start to upgrade one of the users to 1.0-beta.8.1 and then I'll try to start the web gems again. If I get into trouble I'll write another mail.
>>>
>>> I'm glad that you are making good progress.
>> Well, sort of. I managed to upgrade all users so far to 2.4.4 plus 1.0-beta.8.1. Installing pier2 in one turn did not succeed. Choosing a couple of smaller steps worked. Next, starting seaside was easy for the users with 2.8 because the scripts didn't change. For seaside 3.0 it did't went that easy. The script (runSeasideGems30) is somewhat broken. Someone started to change to script so you can specify the web adaptor and the port. But the script seems only halway done. Checks are for $1 as port at the beginning but at the end $2 ist used to start the adaptor. The $1 as adaptor reflects only in the printing stuff :) A
>> runSeasideGems30 "" port
>> is needed to get it going. Then seaside worked.
>
> I've submitted Issue 154 (http://code.google.com/p/glassdb/issues/detail?id=154) for this.
>
>> Finally I'm struggeling with pier. I wrote this in another mail. I discovered that the environment of pier has changed. There are {{{ characters that enclose the html part. Is this official pier stuff? Looks really ugly. But this is what I meant by saying "displayed garbled". Editing the environment and adding those characters made it better. I did not finish on this path because I have an encoding problem and I don't know where it is.
>
> Ah, then SIXX _was_ working correctly:) unless SIXX is the source of your encoding issues...

> On 30.07.2010, at 19:28, Dale Henrichs wrote:
>
>> Norbert Hartl wrote:
>>> On 30.07.2010, at 18:23, Dale Henrichs wrote:
>>>> Norbert Hartl wrote:
>>>>
>>>>> Ok, now I got it runnig with DataCurator. What I did:
>>>>> - copied extent etc fro 2.3.1 installation to 2.4.4.1 installation data dir
>>>>> - startnet && startGemstone
>>>>> - at this stage I could login in with a 2.4.x gemstone client to the unaltered image 2.3.1 image on the new 2.4.4 server. The image was 1.0-beat.6 installed
>>>>> - running the upgradeImage script worked but after that I couldn't log in as DataCurator anymore
>>>> The upgradeImage script has the effect of turning off session methods. With session methods disabled, all of the extension methods that have been added to the base classes are not installed which has the effect of  "disabling" DataCurator logins.
>>>>
>>> Ok, that explains something.
>>>>> - I thought that the upgradeSeasideImage script is mostly recompilation so another bootstrap couldn't harm
>>>> One of the early steps in the upgradeSeasideImage script is enabling sessions methods ... a step that has to be done in order for being able to complete the upgrade steps for Seaside/GLASS
>>>>
>>>>> - bootstrapped DataCurator to 1.0-beta.4
>>>> This step should be unnecessary. Presumably in the end you end up with the same code installed, but I have never tested doing a bootstrap on top of an existing installation....
>>>>
>>>> bootstrapping enables session methods which is one of the critical things that needs to be done for DataCurator.
>>>>
>>>>> - ran the upgradeSeasideImage (not 100% sure if I did)
>>>> if you skip the bootstrap and run the upgradeSeasideImage, this is the point at which you should be able to login using the gemtools client.
>>>>
>>> No, that's where everything started. I did upgradeImage followed by a upgradeSeasideImage but I couldn't log in as DataCurator afterwards.
>>
>> I would be very interested in the error message that you are getting, because that is the scenario that I did test and I didn't have trouble??
>>
>> Have you set up DataCurator to use a different SymbolDictionary other than UserGlobals?
>>
> No. I didn't do any change like that. But now I'm asking myself if it is more safe to redo everything I did the way it is supposed to work. Usually I would think that bootstrapping is not a good idea on an existing image. But then I think that I just overwrite any existing thing and there shouldn't be any side effect while bootstrapping. Do you think I could have damage anyhting? I don't want to introduce a problem now because I want to use the image a longer period.

> Norbert Hartl wrote:
>> On 30.07.2010, at 19:28, Dale Henrichs wrote:
>>> Norbert Hartl wrote:
>>>> On 30.07.2010, at 18:23, Dale Henrichs wrote:
>>>>> Norbert Hartl wrote:
>>>>>
>>>>>> Ok, now I got it runnig with DataCurator. What I did:
>>>>>> - copied extent etc fro 2.3.1 installation to 2.4.4.1 installation data dir
>>>>>> - startnet && startGemstone
>>>>>> - at this stage I could login in with a 2.4.x gemstone client to the unaltered image 2.3.1 image on the new 2.4.4 server. The image was 1.0-beat.6 installed
>>>>>> - running the upgradeImage script worked but after that I couldn't log in as DataCurator anymore
>>>>> The upgradeImage script has the effect of turning off session methods. With session methods disabled, all of the extension methods that have been added to the base classes are not installed which has the effect of  "disabling" DataCurator logins.
>>>>>
>>>> Ok, that explains something.
>>>>>> - I thought that the upgradeSeasideImage script is mostly recompilation so another bootstrap couldn't harm
>>>>> One of the early steps in the upgradeSeasideImage script is enabling sessions methods ... a step that has to be done in order for being able to complete the upgrade steps for Seaside/GLASS
>>>>>
>>>>>> - bootstrapped DataCurator to 1.0-beta.4
>>>>> This step should be unnecessary. Presumably in the end you end up with the same code installed, but I have never tested doing a bootstrap on top of an existing installation....
>>>>>
>>>>> bootstrapping enables session methods which is one of the critical things that needs to be done for DataCurator.
>>>>>
>>>>>> - ran the upgradeSeasideImage (not 100% sure if I did)
>>>>> if you skip the bootstrap and run the upgradeSeasideImage, this is the point at which you should be able to login using the gemtools client.
>>>>>
>>>> No, that's where everything started. I did upgradeImage followed by a upgradeSeasideImage but I couldn't log in as DataCurator afterwards.
>>>
>>> I would be very interested in the error message that you are getting, because that is the scenario that I did test and I didn't have trouble??
>>>
>>> Have you set up DataCurator to use a different SymbolDictionary other than UserGlobals?
>>>
>> No. I didn't do any change like that. But now I'm asking myself if it is more safe to redo everything I did the way it is supposed to work. Usually I would think that bootstrapping is not a good idea on an existing image. But then I think that I just overwrite any existing thing and there shouldn't be any side effect while bootstrapping. Do you think I could have damage anyhting? I don't want to introduce a problem now because I want to use the image a longer period.
>
> Norbert,
>
> I tend to agree that there should be no damage ... the only thing that is going on is that methods are being recompiled and class versions are being created (in cases where shape has changed). Bootstrapping on top of an existing installation used to be fatal ... there were no subtle errors...
>
> A sanity check would be to spin through the loaded packages and see if any changes show up ... if no changes show up then I'd say you are cool ...
>
>