[Glass] Starting Seaside Gems in GS 3.2.8.1

Alejandro Zuzek via Glass glass at lists.gemtalksystems.com
Sun Sep 13 18:29:41 PDT 2015


Hi Dale,

I am happy to announce that I made it work. Essentially, the problem was
that I did not use the right BootstrapApplicationLoadSpecs.

These are the specs that I used which worked:

run
UserGlobals
 at: #BootstrapRepositoryDirectory
 put: GsPackageLibrary getMonticelloRepositoryDirectory.
true
%
run
UserGlobals
 at: #BootstrapApplicationLoadSpecs
 ifAbsent: [
  UserGlobals
   at: #BootstrapApplicationLoadSpecs
   put: {
    { 'ConfigurationOfGLASS' . '1.0-beta.9.1' .
    #('default') . BootstrapRepositoryDirectory } .
    { 'ConfigurationOfSeaside30' . #stable .
    #('default') . '/home/glass/repository/' } .
    { 'ConfigurationOfCarMaintenance' . '0.1-baseline' .
    #('default') . '/home/glass/repository/' } .
   }.
  ].
true
%
commit
logout

I didn't have the Seaside packages locally on the machine I was testing the
upgrade so I ran this to créate a local versión /home/glass/repository/ :

| version cacheRepository mcVersion |
cacheRepository := MCDirectoryRepository new
 directory: (FileDirectory on: '/home/glass/repository/').
"Copy configuration to cacheRepository"
mcVersion := (Gofer new
 gemsource: 'MetacelloRepository';
 package: 'ConfigurationOfSeaside30') resolved first version.
cacheRepository storeVersion: mcVersion.
"fetch packages needed to load Seaside30"
version := ConfigurationOfSeaside30 project version: #stable.
version ignoreImage: true.
version cacheRepository: cacheRepository.
version  fetch.

I got the script from this old post of yours in
https://gemstonesoup.wordpress.com/page/2/ (Helper Scripts for Upgrade of
Seaside 3.0.7.1). I ran a similar script to créate a local repository of my
App (CarMaintenance).

Thanks for all your help,

Alejandro

On Sat, Sep 12, 2015 at 11:37 PM, Alejandro Zuzek <a.zuzek at gmail.com> wrote:

> Hi Dale,
>
> I have tried to upgradeSeasideImage two times (both times starting from
> the same snapshot, where I had just run upgradeImage and I am pretty
> confident that up to that point everything was going well).
>
> In my first atempt, I ran exactly the same BootstrapApplicationLoadSpecs
> as in the Example 4.1 in the 3.2.6 install guide. The next time I ran the
> upgradeSeasideImage script without setting the
> BootstrapApplicationLoadSpecs at all.
>
> In the upgradeSeasideImage log (upgradeTo3x.out) I see this setion:
>
> Automatically generating list of loaded configuration classes to be
> removed:
>   ConfigurationOfGoferProjectLoader
>   ConfigurationOfSeaside30
>   ConfigurationOfGsSqueakCommon
>   ConfigurationOfGsMonticello
>   ConfigurationOfGsFastCGI
>   ConfigurationOfGrease
>   ConfigurationOfGsCore
>   ConfigurationOfMetacello
>   ConfigurationOfSwazoo2
>   ConfigurationOfGLASS
>   ConfigurationOfGsMisc
>   ConfigurationOfGofer
>   ConfigurationOfGsOB
>   ConfigurationOfCarMaintenance
>
> Does this mean that I shoud include a section for each of these
> Configuration classes in the BootstrapApplicationLoadSpecs and not just the
> section for ConfigurationOfGLASS? I do see some of these Configuratioin
> classes in the default bootstrap repository directory (
> *$GEMSTONE/seaside/monticello/repository*) but not all. If this is the
> case, should I also include a section for my own App
> (ConfigurationOfCarMaintenance)? I am asking this, because I don't have a
> copy of ConfigurationOfCarMaintenance and its packages locally on the
> machine where I am upgrading the image and the LoadSpecs appear to expect
> local directories as repositories.
>
> Thanks for all your patience answering these questions.
>
> Alejandro
>
> On Fri, Sep 11, 2015 at 10:54 PM, Dale Henrichs <
> dale.henrichs at gemtalksystems.com> wrote:
>
>> Alejandro,
>>
>> I'm inclined to try to limit the number of variables here ... there are a
>> lot of moving parts involved and I still need to see more detail about how
>> you've upgraded ...
>>
>> Firstly, what did you use for your BootstrapApplicationLoadSpecs (from
>> Example 4.1 in the 3.2.6 install guide[1]).
>>
>> set user DataCurator pass swordfish
>>         login
>>         run
>>         UserGlobals
>>            at: #BootstrapRepositoryDirectory
>> put: GsPackageLibrary getMonticelloRepositoryDirectory. true
>>         %
>>         run
>>         UserGlobals
>>            at: #BootstrapApplicationLoadSpecs
>>            ifAbsent: [
>>               UserGlobals
>>                  at: #BootstrapApplicationLoadSpecs
>>                  put: {{ 'ConfigurationOfGLASS' . '1.0-beta.9.1' .
>>                         #('default') . BootstrapRepositoryDirectory } . }.
>> ]. true
>> %
>> commit
>> logout
>>
>> You should have provided a configuration and version that would ensure
>> that your whole application gets reloaded at the end of the upgradeSeaside
>> script. Getting an MNU makes me think that you haven't arranged to load
>> your entire application into the upgraded image.
>>
>> Secondly, have you loaded your application code into GS 3.2.8.1 and
>> verified that it works correctly. This is important because it eliminates
>> any variables that might be introduced by the upgrade process and also
>> gives you an assurance that your application should work correctly in
>> 3.2.8.1 ... also you'll have the opportunity to fix any platform specific
>> bugs ...
>>
>> Dale
>>
>> [1]
>> https://downloads.gemtalksystems.com/docs/GemStone64/3.2.x/GS64-InstallGuide-3.2.6-Linux.pdf
>>
>> On 9/11/15 5:14 PM, Alejandro Zuzek wrote:
>>
>> Hi Dale,
>>
>> I am still unable to make the upgraded image work, that is, I still
>> cannot start the Seaside Gems. I rerun the whole installation process on a
>> backup of my 3.1.0.4 system, including running upgradeImage and
>> upgradeSeasideImage. No errors were reported there, by the WAGemStoneRunSeasideGems
>> class still doesn't understand #'startGemServerOn:
>>
>> I tried to reload the Seaside Adaptors with this code:
>>
>> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>>   ConfigurationOfMetacello project updateProject.
>>   ConfigurationOfMetacello loadLatestVersion.
>>   Gofer project load: 'Seaside30' group: #('Seaside-Adaptors-FastCGI' 'Seaside-Adaptors-Swazoo').].
>>
>> but I get this error:
>>
>> --transcript--'redirecting to
>> http://seaside.gemtalksystems.com/ss/Seaside30/Seaside-Adaptors-FastCGI-dkh.26.mcz
>> '
>> --transcript--'Fetched -> Seaside-Adaptors-FastCGI-dkh.26 ---
>> http://seaside.gemstone.com/ss/Seaside30 ---
>> http://seaside.gemstone.com/ss/Seaside30'
>> ERROR 2718 , a ArgumentError occurred (error 2718), (argument at: 1)
>> contains codePoint 16rd800 not legal for Unicode (ArgumentError)
>>
>> Is it possible that the .26 version of FastCGI is broken (illegal
>> character?) and that this is preventing upgradeSeasideScript to reload
>> FastCGI code correctly?
>>
>> Thanks,
>>
>> Alejandro
>>
>> On Sun, Sep 6, 2015 at 11:50 PM, Dale Henrichs via Glass <
>> glass at lists.gemtalksystems.com> wrote:
>>
>>> Alejandro,
>>>
>>> It sounds like you didn't reload your application code after the
>>> upgradeSeasideImage completed - your "application code" includes anything
>>> that was loaded on top of GLASS, including running upgradeImage, loading
>>> Seaside code and your Seaside application itself ...
>>>
>>> I have written an upgradeGemStone script[1] (on the dev branch) for
>>> automating the upgrade steps (the script uses a user-specified tODE shell
>>> script to load your application code) and you might want to look at the
>>> script itself for inspiration ... feel free to ask additional questions.
>>>
>>> Dale
>>>
>>> [1]
>>> https://github.com/GsDevKit/gsDevKitHome/blob/dev/bin/upgradeGemStone
>>>
>>> On 9/5/15 4:05 PM, Alejandro Zuzek via Glass wrote:
>>>
>>>> I have just migrated from GS 3.1.0.4 to GS 3.2.8.1 (I followed the
>>>> procedure,
>>>> including running upgradeImage and upgradeSeasideImage scripts). In
>>>> 3.1.0.4
>>>> I would start the Seaside gems with this command:
>>>>
>>>> runSeasideGems30 start WAFastCGIAdaptor "9001 9002 9003"
>>>>
>>>> When I run the same command in the 3.2.8.1 version, the Gems don't
>>>> start and
>>>> in the start logs (for instance in WAFastCGIAdaptor_start-9003.log) I
>>>> see
>>>> this error:
>>>>
>>>> a MessageNotUnderstood occurred (error 2010), a WAGemStoneRunSeasideGems
>>>> class does not understand  #'startGemServerOn:'
>>>>
>>>> Furthermore, in the new versión while the class WAGemStoneRunSeasideGems
>>>> exists, it doesn't have any methods at all.
>>>>
>>>> In the upgradeSeasideImage output (upgradeTo3x.out) I see many clases
>>>> being
>>>> loaded, but no trace of WAGemStoneRunSeasideGems). The script ended
>>>> sucessfully and I don't see any errors in the output log.
>>>>
>>>> Was there a problem in the upgrade of my image or is this intended and
>>>> there
>>>> is now a new procedure to start Seaside gems?
>>>>
>>>> Thanks,
>>>>
>>>> Alejandro
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://forum.world.st/Starting-Seaside-Gems-in-GS-3-2-8-1-tp4848347.html
>>>> Sent from the GLASS mailing list archive at Nabble.com.
>>>> _______________________________________________
>>>> Glass mailing list
>>>> Glass at lists.gemtalksystems.com
>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>
>>>
>>> _______________________________________________
>>> 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/20150913/375f76d7/attachment-0001.html>


More information about the Glass mailing list