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

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.

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).

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 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.

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?

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

On Mon, 2014-02-24 at 09:18 -0800, Dale Henrichs wrote:

> 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.

Ok, I thought those were obsolete kernel classes; but handling them in
upgradeSeasideImage makes sense after your explanation.

>         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 was not a matter of something needing to be added to the list;
something already added to the list was broken. What happened is that
OTRemoteDebugger had lost all its methods (including #sessionStart),
which caused a DNU when SystemLoginNotification tried to call it at
login time, which caused topaz to increment its errorcount, and made all
topaz scripts fail with exit code 1 thereafter, and all kinds of other
fun in gemtools and stopstone.

I now understand this is due to upgradeSeasideImage looping over all
classes in UserGlobals and doing removeAllMethods class side and
instance side. Without a working #BootstrapApplicationLoadSpecs, the
majority of the removed methods never got re-added at all.

So tomorrow I'll focus on getting a BootstrapApplicationLoadSpecs that
somehow pulls in BaselineOfGLASS1 and see how that goes.

> I don't think you should hack the upgradeSeasideImageScript.

The alternative seems to be generating an equivalent MCZs repository for
all the filetree stuff, and then I'd have to automate the creation of
that repository into our build process so it stays in sync with the
github filetrees - I dislike manually created copies of data that can
get out of sync.

I'll experiment with an empty #BootstrapApplicationLoadSpecs, but
instead somehow create a class whose initialize just calls our existing
source code bootstrapping scripts (that load the new Metacello,
filetree, BaselineOfGLASS, and our code). I can arrange for that to be
triggered via #BootstrapApplicationLoadSpecs. That should circumvent the
need to edit upgradeSeasideImage and give me a hook to load our code
with a newer Metacello.

I managed to run through upgradeSeasideImage without any (obvious)
errors with the advice given here.

But now I can't load Seaside30. As part of it, a class-side #initialize
is triggered that tries to set an #exceptionHandler on the application
configuration, but Seaside moans that the specific attribute does not
exist.

My main problem is that I cannot debug what is going on. When I log in
to the repository via topaz afterwards, all the methods that I saw in
the stack trace are just gone. I went so far as to compare the oops of
the classes in the stacktrace to the oops of the classes in the
repository, and they're all the same. I also tried to wrap the loading
code in an "[...] ensure: [System commitTransaction]" block, to no
avail. 

Does metacello have an error-handler that unloads all methods it loaded
on error? (Remember, the state that upgradeSeasideImage left the
repository in is that it deleted all methods on all classes in
UserGlobals, so any rollback would leave the repository in that state).

Alternatively, is there any way to tell Metacello to not call
#initialize on classes? I suspect that what's happening is that the
missing methods that upgradeSeasideImage deleted breaks some descriptors
of some Seaside classes, which get queried (and cached on the
#description instvar) at a point before the source code is reloaded, and
thus Seaside does not relaise that #exceptionHandler is a valid
configuration. If this is the case, I can use Metacello to load the code
twice, and only enable #initialize the second time.

--
Pieter Nagel





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

On Fri, 2014-02-28 at 10:46 -0800, Dale Henrichs wrote:
>
>
>
> On Fri, Feb 28, 2014 at 4:45 AM, Pieter Nagel <[hidden email]>
> 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


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