Configuration

Jarvis Configuration

We've tried to make Jarvis configuration very flexible. Configuration settings can be:

1. passed as environment variables when starting APL
2. stored in a JSON file specified by the ConfigFile setting
3. passed as constructor arguments when creating the Jarvis instance
4. set after the creation of the instance but before starting the server

The order above is the order in which settings, if set from more than one source, are applied. Settings set after creation take precedence over constructor arguments which take precedence over configuration file which take precedence over environment variables.

Common Settings
These are settings that are independent of which paradigm you use. The most commonly used settings are found at the top of the list, otherwise the list is alphabetical.

Setting	Description	Notes
CodeLocation	The location for where to find your application code	Default: # A reference to a namespace in your workspace or a file path from where to load the code
Port	Port for the server to listen on	Default: 8080
Paradigm	The paradigm for your webservice. Either 'JSON' or 'REST'	Default: 'JSON'
ConfigFile	Name of the JSON file, if any, containing configuration settings.	Default: ''
Debug	Sets debugging level. 0 = all errors are trapped 1 = stop on error 2 = stop before execution of application code 4 = stop after request is received	Default: 0
LoadableFiles	Comma-delimited list of patterns of files to load when CodeLocation specifies a folder for your application code.	Default: '*.apl*,*.dyalog*'

Application Hook Settings
These are settings where you specify the name of a function you write and will be, by default, found in CodeLocation

Setting	Description	Notes
AppInitFn
AuthenticateFn
RESTMethods	specifies the HTTP methods your service will support	RESTServer only
SessionInitFn
ValidateRequestFn

Session Settings
These are settings related to maintaining sessions/state in the server.

Setting	Description	Notes
SessionCleanupTime
SessionIdHeader
SessionPollingTime
SessionStartEndpoint
SessionStopEndpoint
SessionTimeout

Request Settings
These are settings related to the HTTP requests and responses that Jarvis manages.

Setting	Description	Notes
DefaultContentType
FlattenOutput
ParsePayload

Communication Settings\

Setting	Description	Notes
AcceptFrom
BlockSize
DenyFrom
Secure
ServerCertFile
ServerKeyFile
SSLValidation

Detailed Discussion of Certain Settings

CodeLocation
CodeLocation tells Jarvis where to look for your application code as well at any application hooks. There are two options for CodeLocation.

• A namespace reference within your workspace. Jarvis assumes that all of your code is already loaded in the namespace.
• A path to folder containing your code. In this case Jarvis creates a namespace #.CodeLocation and loads, recursively if necessary, any files matching the patterns specified by the LoadableFiles configuration setting.

Debug
Debug is used primarily during development of your webservice. In production, Debug should be set to 0. Debug's values are additive; for instance, a value of 6 would cause stops for both application calls as well as when the complete HTTP request is received. The valid setting are:\

• 0 - no stops are set and all errors in either the application or the Jarvis framework are trapped.
• 1 - stop when an error occurs (turn trapping off). This is used primarily for debugging the Jarvis framework.
• 2 - stop when your application code is about to execute. This is used to debug your application and whatever hooks you have implemented. When stopped, you may step through your code.
• 4 - stop when a complete HTTP request is received. This is used primarily for testing the Jarvis framework.

RESTMethods (RESTServer only)
RESTMethods specifies the HTTP methods that your service will support and the APL functions that will implement each method.

RESTMethods is a character vector of comma-delimited HTTP method/APL function name pairs. If no APL function name is specified, it is assumed to be the same as the HTTP method. Note that while HTTP methods are case insensitive (get GET Get GeT will each match the GET method), the APL function name is case sensitive. For example:

      RESTMethods←'Get,Post/MyPostFunction'

Specifies that the service will support the HTTP GET and POST methods and the APL functions you will write will be named Get and MyPostFunction.

For more information see Building REST Services.