Each of these can be set in the .config files, but they can be overridden with the command line. Run AppServer with switches in the form --ClassName.SettingName=value, e.g. --AppServer.Port=1
The value is coerced into a Python type: if it starts with one of the characters ({["' -- i.e., parenthesis (expression), dictionary, list, or string -- then the value with be eval'ed. If it can be turned into an integer or float, then it will be converted, otherwise it will be left as a string. Some examples:
Be careful about special characters in the shell. All the characters () [] ' " are special, and need to be quoted (with \ or with single or double quotation marks).
Application.config covers not only the application, but a number of components that use it as a central point of configuration.
This dictionary maps context names to the directory holding the context content. Since the default contexts all reside in WebKit, the paths are simple and relative. The context name appears as the first path component of a URL, otherwise Contexts['default'] is used when none is specified. When creating your own application, you will add a key such as "MyApp" with a value such as "/home/apps/MyApp". That directory will then contain content such as Main.py, SomeServlet.py, SomePage.psp, etc. Webware/bin/MakeAppWorkDir.py will set up a context for your use as well. Default:
{ 'default': 'Examples', 'Admin': 'Admin', 'Examples': 'Examples', 'Docs': 'Docs', 'Testing': 'Testing', }
These configuration settings control which files are exposed to users, which files are hidden, and some of how those files get chosen.
This setting can be used to prefix the session IDs with a string. Possible values are None (don't use a prefix), "hostname" (use the hostname as the prefix), or any other string (use that string as the prefix). You can use this for load balancing, where each Webware server uses a different prefix. You can then use mod_rewrite or other software for load-balancing to redirect each user back to the computer they first accessed. This way the backend servers do not have to share session data. Default: None. @@ ib: need a better mod_rewrite link.
This setting controls the manner in which WebKit serves "unknown extensions" such as .html, .gif, .jpeg, etc. The default settings specify that the servlet matching the file be cached in memory, that the contents of the file be cached in memory and that the file timestamp to be checked on every request. This works well for most sites.
If your site has a large amount of static files being served via WebKit, you should consider changing "CacheContent" to 0. If you are confident that your static files do not get updated while the app server is live, then you might consider changing "CheckDate" to 0 for (slightly) better performance. If you are concerned about performance, use mod_rewrite to avoid accessing WebKit for static content. @@ ib: link to mod_rewrite
The Technique setting can be switch to "redirectSansAdapter", but this is an experimental setting with some known problems. Default:
{ 'ReuseServlets': 1, # Technique choices: # serveContent, redirectSansAdapter 'Technique': 'serveContent', # If serving content: 'CacheContent': 1, # set to 0 to reduce memory use 'CheckDate': 1, }
If true, then display a fancy, detailed traceback at the end of the error page. It will include the values of local variables in the traceback. This makes use of a modified version of cgitb.py which is included with Webware. The original version was written by Ka-Ping Yee. Default 0 (off).
The e-mail headers used for e-mailing error messages. Be sure to configure "From", "To" and "Reply-to" before turning EmailErrors on. Default:
{ 'From': '-@-.com', 'To': ['-@-.com'], 'Reply-to': '-@-.com', 'Content-type': 'text/html', 'Subject': 'Error' }
When the application server starts up, it looks in these locations for plugins. Each plugin is a subdirectory of its own. By default WebKit looks in the Webware/ directory (..) for plugins -- several of which are shipped with Webware. Default [".."]. See Creating Plugins for information on creating your own plug-ins. @@ ib: are these really differently cased?
The advantage of a plug-in directory is that you can add new plug-ins to the app server simply by dropping them into the directory; no additional configuration is necessary.