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

[Dale Henrichs]

On Fri, Feb 28, 2014 at 12:07 PM, Pieter Nagel <pieter at nagel.co.za> wrote:

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


Okay.

>


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

Yes and I agree that this is a good plan...

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

So the methods that go missing are in the process of being loaded ... for
the first time... and are on the stack at the point or error, but seem to
disappear afterwards ... So if the #initialization tricks don't help I'd
like to see a stack trace at the point of the error
... MCPackageLoader>>tryToLoad: and friends are pretty complicated beasts,
but I don't think there is any logic where already compiled methods are
removed, but a stack would help narrow the search space ...

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

Yes and for loading the GLASS base packages, I think that the
 BootstrapApplicationPostloadClassList is sufficent.

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

The final round of loads are intended to define the methods that were
removed in the earlier steps and at your point in time, if you've only
loaded in the GLASS stuff, then this is consistent ...


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

Yes ... this sounds good ... if you still get errors, share the actual
stack with me, so that I can look for suspicious exception handlers ...

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/7dec0eb3/attachment.html>