[Glass] Upgrade GS 2.4 -> GS 3.1 when GLASS, Seaside etc. versions have already diverged

[Dale Henrichs]

On Mon, Feb 24, 2014 at 6:59 AM, <pieter at nagel.co.za> wrote:

>
> Hi,
>
> I'm struggling to upgrade a 2.4.4.4 repository to 3.1.0.4. I suspect the
> root problem is that the loaded metacello packages
> have massively diverged from the "blessed" versions that shipped with
> 2.4.4.4 in extent0.seaside.dbf, and that just breaks
> too many hard-wired assumptions in upgradeSeasideImage. For example, we're
> using recent versions of Metacello, Seaside30,
> GLASS and Zinc as published on github, we're using filetree, and that
> implies a lot of changes in lower-level dependencies
> such as Sport and SoXML etc.
>

Yes, please take a look at Johan's thread for clues to address some of the
issues (and of course ask more questions if it still isn;t completely clear.

>
> To my thinking, we don't need to run upgradeSeasideImage since we've
> already upgraded Seaside; we just need to run upgradeImage
> to deal with changes in kernel classes and the GemStone product itself.
> However, when I inpect upgradeSeasideImage.topaz, it
> seems to contain code that relates to the upgrade from 2.4 -> 3.1
> itself (for example, making ControlInterrupt, Halt, Pause, Random,
> TransientRandom and BreakpointNotification obsolete).
>

The upgradeSeasideImage script is intended to provide a framework for
upgrading the basic GLASS support classes to the proper versions needed to
function in 3.1 as well as reload all of your packages as well.

In 2.x a number of the exception classes were part of GLASS and were
subclassed off of the class ExceptionA. In 3.x some of the exception
classes are part of the base and the ExceptionA class no longer exists (it
is an obsolete class) ... the upgradeSeasideImage script does the dirty
work to make this type of transition as simple as possible.

There are differences in the GLASS support classes and there are
differences in the Seaside classes between 2.x and 3.x so it is really
necessary to do a full Metacello load of your entire application to
complete the upgrade process and the upgradeSeasideImage script has support
for that as well.

>
> So it seems we do need to run upgradeSeasideImage, but ensure that it
> does not trip over our different version numbers. But then
> bootstrapMaster30.topaz becomes an issue: it forcibly loads a bunch of
> hard-wired version numbers of MCZs for Metacello, Monticello and so
> on, and surely those version numbers are totally wrong for our
> dependencies?
>

The upgrade process is sometimes pretty complicated to compensate for new
capabilities and functionality ... for 3.x upgrades all methods must be
recompiled (they will not exectue otherwise)...the upgrdeScriptSeasideImage
script basically does a complete bootstrap from an empty image and starts
by bootstrapping GLASS (which is why the old code is loaded)... further
into the script the GLASS version that you are using is loaded into the
image, followed by a reload of your entire application class base ...

>
> The most common problem I have is that the image just ends up with
> crucial methods and classmethods totally gone on classes that are
> subscribed to SystemLoginNotification, causing login errors that trips
> up topaz, stopstone, gemtools.
>

Is this after you have done a upgradeSeasideImage? There is a global that
can set before starting the upgrade (BootstrapApplicationPostloadClassList)
where you  define the list of classes that you want to have initialized
after the upgrade ... unconditional sending of #initialize during the
upgrade process could wipe out critical data structures so this "opt-in"
process was adopted so that you know exactly which initialize messages are
being sent ... for the SystemLoginNotifications it sounds like those
classes involved need to be added to the list.

>
> It seems that the culprit is #BootstrapApplicationLoadSpecs - it
> seems it should list enough ConfigurationOf packages to reverse the
> effect of upgradeSeasideImage that deleted all methods in
> UserGlobals. But we're way past using ConfigurationOfGLASS now, we're
> using BaselineOfGLASS1 as published on github.
>
> So I tried something like
>
> UserGlobals
>   at: #BootstrapApplicationLoadSpecs
>   put: {
>     { 'BaselineOfGLASS1'. 'baseline'. #('default').
> 'filetree:///home/wonka/development/wonka/3rdparty/glass/repository/'}
> }.
>
> but that doesn't work, since its Gofer doing the loading and Gofer
> does not seem to be able to resolve BaselineOfGLASS1 from a filetree
> repository.
>
> Should I just hack at upgradeSeasideImage.topaz to load
> BaselineOfGLASS1? Has anyone else ever been in a similar situation?


Read through Johan's post first and supply some more information about how
you've defined  the variouse globals used in the upgradeSeasideImage script:

#BootstrapSymbolDictionary
#BootstrapSymbolDictionaryName
#BootstrapRepositoryDirectory
#BootstrapApplicationLoadSpecs
#BootstrapExistingConfigurationList
#BootstrapApplicationPostloadClassList

I don't think you should hack the upgradeSeasideImageScript. There's a
description of the above variables in Chapter 4 of the Install Guide that
should help as well

Dale

>


> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glas<http://lists.gemtalksystems.com/mailman/listinfo/glass>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140224/5c215937/attachment.html>