This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Starting up a VW web app Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

Periodically, people ask how to go about setting up a VW web application to auto-configure itself at startup. The plan is to make all of that easy via the existing settings tools - as with other VW settings, that stuff could all be loaded at startup. That doesn't hep now though; the existing tools were designed with the idea that you would run a server with an editable (GUI) console and configure, or that you would save the image in the proper state and just run it.

I ran into this same issue when I was setting up the Wiki and this blog server a few years ago, and I created the WaveConfigurator package (check the public store) to deal with it. Basically, it allows you to specify an ini file of settings that will be checked at startup. Here's what the ini looks like for the test server I run on my local Linux box:

[WaveConfiguratorSettings]
type='VisualWave.IPWebListener'
port=2223
baseResolvers=''
baseServices=''
serverNameForSocketBindings='victoria'

The blank settings are a legacy of classic Wave - they allow for the setup of old style servers that use the 'launch' capability. The rest of it is pretty simple - type is the class name, port is the port, and the serverName setting specifies which name to bind the socket to - which is good if you don't want the server socket bound to every IP on the server. I've been using this scheme to have servers start themselves up for awhile now. Combine that with a command line argument to load a specific parcel, and you can set pre-requisites such that a base image will load everything up and just go.

As to how to get that base image - for servers, I don't bother to use RuntimePacker. I simply save the development image headless (i.e., no GUI), and have the startup process configure everything else. The nice thing about that is that I can then script in a command to save the image with a GUI, download it - and debug any odd server issue in the context that it actually occured (try that with a Java or .NET based service :) ).