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

[Pieter Nagel]

On Fri, 2014-02-28 at 10:46 -0800, Dale Henrichs wrote:
> 
> 
> 
> On Fri, Feb 28, 2014 at 4:45 AM, Pieter Nagel <pieter at nagel.co.za>
> wrote:
>         I managed to run through upgradeSeasideImage without any
>         (obvious)
>         errors with the advice given here.
> Do all of your unit tests pass and are you able to see all of the
> source at this point in time? 

To be clear: I use upgradeSeasideImage *only* to load 1.0-beta.9.1, and
not our own application or its dependencies (Seaside, Zinc, etc.) This
is because we have upgraded to a lot of dependencies published on github
as filetree repositories, and upgradeSeasideImage can't handle that, as
mentioned earlier on this thread.

So my aim was for upgradeSeasideImage to get the repository similar
enough to extent0.seaside.dbf that we can just invoke the exact same
scripts that work against that to load the newer GLASS (as published on
github) and all our other dependencies.

It is during this process that the error occurs, and the methods all
just seem to disappear after topaz dumps a stack trace that makes it
very clear that the methods did exist at the point of error.

> I'm curious if you used BootstrapApplicationPostloadClassList scheme
> when loading your own code.

No, all I set was BootstrapApplicationLoadSpecs to load GLASS 1.0-beta.9
and then GLASS 1.0-beta.9.1 as you suggested earlier in this thread.

> This type of thing _shouldn't_ happen during a normal
> upgradeSeasideImage run (and doesn't in our test environments or for
> other folks who have done upgrades), so there must be something that
> you are doing different...

Yes, as mentioned, the error occurs *after* a normal upgradeSeasideImage
run.

> I also want to make sure that you have ported all of your code to 3.1
> before attempting the upgrade as there may be other things going on
> that cause the problems ... 

The exact same code base, loaded onto a 3.1 extent0.seaside.dbf by the
exact same scripts I run after upgradeSeasideImage, passes all unit
tests in that "clean slate" scenario.

> I asked earlier if before trying to load seaside and getting this
> walkback that you have verified that all of the method source is
> visible, because I want to make sure that we're debugging the right
> thing.

Only GLASS-related method source is visible. All other classes are still
in their "removeAllMethods" state as upgradeSeasideImage made them; the
hope was that by running our code loading script the rest of all the
methods would also be loaded.

What I take from your message is that I need a suitable
MCPerformPostloadNotification handler to suppress #initialize methods;
and that the session method machinery is a likely explanation for why
the methods seem to disappear - if that persists I should look at what
upgradeSeasideImage did in that regard and run our scripts in the same
type of context. These are good leads, thank you.

--
Pieter Nagel