All elements of SP are configured via the configuration file that comes in the standard .properties format. Config file resolution is described in the configuration documentation. The base configuration directory can differ from platform to platform (the default on Unix and Linux is /etc/masterkey/service-proxy/). All examples provided on this page and appropriate plugin pages are simply entries from real config files.
SP plugins are Java classes that implement the Plugin interface (provided in the in the service-proxy-plugin-api archive). A plugin can be used in a chain as long as the appropriate plugin class (and its dependencies) has been supplied to the SP runtime enviroment e.g by placing the JAR file containing the plugin on the servlet container classpath or by "packaging" the classes along with the SP web application (the core plugins are distributed this way). Otherwise SP will not able to instantiate the plugins when they're registered.
Plugins are registered by specifying the fully qualified classname and assigning them a readable name (chains and plugins are special keywords and cannot be used as names).
plugins.some_plugin_name = com.mycompany.plugins.SomePlugin
Example:
plugins.relay = com.indexdata.serviceproxy.plugins.Pazpar2RelayPlugin
Use only alphanumeric characters and underscores in the plugin names.
Configuration properties for a specific plugin are described in the appropriate plugin manual page. In general, configuration properties are specified using the assigned plugin name followed by a '.' and property name. Property names are case sensitive, and are conventionally spelled in all upper-case.
some_plugin_name.SOME_PROPERTY = some value
Example:
relay.PROXY_MODE = 3
Chains are used to combine plugins into processing pipelines. Each plugin performs a similar task: reads parameters and data from the request and writes to (or updates) the response. After performing its task the plugin can choose whether to continue executing the chain or stop immediately, returning the response to the client. In the configuration, chains are expressed as ordered lists of registered plugin names (comma-separated):
chains.some_chain_name = some_plugin_name1,some_plugin_name2
Example:
chains.record = relay,ace
Chains automatically map to the command request parameter, so the following GET request:
GET /service-proxy/?command=some_chain
Invokes the some_chain chain.
It's possible to include a fallback chain by using a wildcard match ('*'), in which case a command without an explicit mapping will trigger the fallback chain.
Example:
chains.* = relay #proxy all other commands to Pazpar2
