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

[Dale Henrichs]

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?

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

I'm curious if you used BootstrapApplicationPostloadClassList scheme when
loading your own code. To Monticello it will appear that none of the
#initialize methods are present so Monticello will run the #initialize
method after installing it ...  Since this is an upgrade you likely don't
want the standard #initialize behavior since it may wipe out any state that
you have defined ... this applies to Seaside as well as your own
application .... the upgradeSeasideImage.topaz process uses an "opt-in"
model for #initialization, but if you didn't have a handler
for MCPerformPostloadNotification in your loading process, then you will be
running all of the initializations which is probably not what you want ...


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


There is no such thing as "remove methods on error". OTOH there are ways
for methods to "disappear".

In a normal GemStone repository it is not possible for DataCurator to add
methods to classes in the Globals symbol dictionary, but in GLASS we have
enabled session methods, which do allow one to add methods to the classes
in the Globals symbol dictionary. If you disable session methods then the
methods would effectively disappear.

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

Perhaps you could share the specifics of your upgrade process?

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

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.

>
> 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).
>
The steps at the end of the upgrade process  are intended to install of the
methods deleted during earlier steps ... there are commits at the end of
each step (and GsDeployer class >>bulkMigrate: should be doing automatic
commits on out-of-memory conditions) and once you've committed GemStone has
not way of rolling back to a previous commit short of restoring from backup
and replaying selected tranlogs ...


> 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.
>
> Yes in GLASS Monticello  signals a MCPerformPostloadNotification before
sending #initialize and you can control which classes you want to have
initialized and which ones you don't ... as I mentioned earlier the
upgradeSeasideImage process skips initialization unless you explicitly
specify a class ...

Dale

>
> --
> Pieter Nagel
>
>
>
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140228/25ffed31/attachment.html>