ReferenceToMissingMethod and a Seaside packaging problem

[PhotonDemon]

Hi,

I'm playing with packaging a simple Seaside demo with the idea of learning how to run it on Linux, where I have almost no experience. I'm starting out by packaging it for windows and as a windows NT service, where I do have some experience. I'm having a problem with running the windows image, which I'm sure is a packaging problem. I will get to that in a minute.

While looking around at the Seaside code, I find that there are some methods that use methods that are missing. I expect that this is due to the fact that Seaside comes from the Squeak/Pharo world and that those Smalltalks have methods that aren't in our Smalltalk.

I have a snippet of code that I use to check some of my apps to see if I have forgotten to write a method. The code below is it's core and checks one app. It can be wrapped with some code that feeds it app names and checks more than one app. It puts the results in a stream but that can be changed to output to a file or kept in a collection or whatever. Everyone should feel free to use it to check their code if that wish.

Code: Select all

| stream app allLocalClasses |

app := SeasideCoreConfiguration.
stream := WriteStream on: (String new: 500).
allLocalClasses := app allLocalClasses.
stream nextPutAll: app name; cr.
allLocalClasses do: [:c |
   (c class methodsArray) do: [:m |
      m stsHasReferenceToMissingMethod ifTrue: [stream tab; nextPutAll: m name; cr].
   ].
   (c class primaryInstance methodsArray) do: [:m |
      m stsHasReferenceToMissingMethod ifTrue: [stream tab; nextPutAll: c name; cr].
   ].
].
stream contents.


Now back to my problem (sorry for putting two topics in one post).

To get my Seaside demo started I execute the following:

Code: Select all

WAAdmin register: self asApplicationAt: 'SeasideDemo'.

When I worked on a Seaside project about two years ago, this was the thing to do. When I test in the envelopment environment, everything works fine. However the packaged image blows up.

WASharedConfiguration(WAConfiguration)>>#ancestorsDo:seen:

runs its #parents that for some reason has a nil object in the
OrderedCollection(a WARenderLoopConfiguration nil ).

The nil causes halt. This smells like a class is missing from the packaged image so that the nil is added to the collection and not an instance of the class. But I can't figure out what class is missing.

I create all the ".es" files when I package and when I look at them and especially classes.es, I don't find anything that helps. I just remembered that when I last played with Seaside, overly reduced pool dictionaries might have been a problem. I will see if not reducing pool dictionaries helps.

Lou

[TriSebastian]

Hi!

I think there's nothing missing. The reason for this has the same reason like the impossibility to reload Seaside twice into an image.

I guess the nil Object is related to a WASharedConfiguration that existed prior to the packaging process taking place. Once your image got packaged and the server starts your old WASharedConfiguration is nil.

Have you tried packaging a seaside server without starting the ServerAdaptor in your image? This should work.

I had also trouble with this. Have a look at all the senders of copy in the seaside applications. They prevent a lot of cleanup during startup and reset of your system.

GreasePlatform registers it's self into the system startup and due to all the copies there are still things like configurations and sessions sometimes nil sometimes not still present in your image. That's something that should urgently be solved.
Pharo doesn't have this problem, because the don't have certain startup and load initialization logic like VASt has.

I hope this helps. If not, please post again,... I had the problem,too.

Sebastian

[TriSebastian]

Hi again!

I had a look. Marten and I had a little "try to package seaside" session a few weeks ago and indeed it seems like I had also missing classes in my package.

Please try to add this to you main application class on class side, if the already mentioned thing above doesn't work out:

packagingRulesFor: aPackagedImage

aPackagedImage doNotReduceSubApplicationNamed: self symbol.
aPackagedImage doNotReduceSubApplicationNamed: #SstHttpServletSupport.
aPackagedImage doNotReduceSubApplicationNamed: #SeasideToolsCoreApp.
aPackagedImage doNotReduceSubApplicationNamed: #SeasideAdaptorsSst.
aPackagedImage doNotReduceSubApplicationNamed: #GreaseVASTCore.
aPackagedImage doNotReduceSubApplicationNamed: #SeasideCoreServer

Hope this helps a little,
Sebastian

[PhotonDemon]

Hi Sebastian,

Thanks for both your replies. Let me address your second post first. I have some packaging instructions that cover some of your suggestion. I added all of yours where you suggested but it made no difference.

Your first post has some interesting points and got me thinking. As for

Have you tried packaging a seaside server without starting the ServerAdaptor in your image?

I assume your talking about starting the ServerAdaptor in my development image. I remember this being a problem from when I played with Seaside a couple of years ago. I try to always package from a clean image and for sure don't test Seaside in development and then package.

I guess the nil Object is related to a WASharedConfiguration that existed prior to the packaging process taking place. Once your image got packaged and the server starts your old WASharedConfiguration is nil.

Here I think you are on to something. When I

Code: Select all

WASharedConfiguration allInstances inspect

I find two instances, one of which has two parents, one of which is a WADevelopmentConfiguration.

When I test, the code blows up running a list of parents, one of which has gone nil. Since the item above is a parent and the WADevelopmentConfiguration probably isn't in the packaged image and probably shouldn't be, it looks like the culprit.

Now the question is what to do about it? My goal is to be able to package a Seaside program to run on Linux, which I know little about and requires using an XD image, which I also know little about. So, I am starting with a Windows NT service, which I do know something about and working my way to a Windows NT service form an XD image and then a Linux image. Maybe the Windows XD image won't have the WADevelopmentConfiguration problem. But I'm having problems getting everything needed into the XD image.

I will let you know how things go.

Lou