Skip to content

ORS Configuration

Jump to bottom Edit New page
haymant edited this page Jul 25, 2020 · 3 revisions

ORS Configuration

Author: [email protected]
Since: 1.1.0
Version: $Id: README.html 16154 2012-07-14 16:34:05Z colin $

$License$

[

Index

]()[ ]()

[

Configuration files

When the ORS is started using the `runORS` script (`runORS.sh` on UNIX and its variants and `runORS.bat` on Windows), it looks for its configuration in the `server.xml` file within the `conf` subdirectory of the ORS installation.

The ORS can be minimally configured via `server.xml`, which can instantiate all configuration objects. However, to keep that one required file small and readable, the default configuration is split across multiple Spring files, which `server.xml` imports. Each such file covers a functionally distinct area of the ORS, such as the configuration of brokers or the database. In more depth, the default configuration uses a consistent pattern whereby each functional area's configuration resides within files in a subdirectory, and each subdirectory has a `main.xml` file that imports all other files in that same subdirectory; to import the contents of this subdirectory from files outside it, `main.xml` alone is imported.

Besides clarity, another advantage of this configuration partitioning is that the CLI script `orsadmin` (`orsadmin.sh` on UNIX and its variants and `orsadmin.bat` on Windows) may be configured without duplicating configuration objects: instead, `cli.xml` imports some of the same Spring files as `server.xml`.

Strictly speaking, this partitioning into multiple files and overall organizational method is arbitrary, and the end-user may change it at their own discretion; that said, a change in organization is discouraged because it may complicate migration to later version of the ORS.

In addition, via `properties.xml` imported from `server.xml` (as well as from `cli.xml`), part of the configuration is relegated into two standard Java properties files: `default.properties` and `user.properties`. These files define certain name-value pairs, which then the Spring configuration files may reference using the `${name}` syntax. It is also possible for the values of other name-value pairs in these files to refer to such names using the same `${name}` syntax. This technique centralizes certain preferences that appear within multiple Spring configuration beans, such as the ORS's host name, easing the task of changing it.

Variable names, as well as the choice of which settings to relegate into properties file, are again arbitrary, and the end-user may change all this at their own discretion. It is also possible to eliminate the properties files altogether, and place the values in-line within the Spring files, e.g. replace sections such as

 <property name="serverHost" value="${metc.ws.host}"/>

with

 <property name="serverHost" value="localhost"/>

This approach may be cleaner for some end-users, but it also has the drawback that certain key operational parameters may need to appear in more than one place, thereby making changes harder.

The reason that two properties files are used, instead of one, is that `user.properties` may override default values set in `default.properties`. This makes it possible to start off with a simple and minimal custom configuration in `user.properties`, and gradually override additional properties from `default.properties` as the end-user makes further refinements to their installation, while retaining an easy way to revert to the original defaults: just delete the overriding line from `user.properties`, and the line in `default.properties` will kick back in. Moreover, migration to new ORS versions is easier as site-specific customizations are limited to a single file, `user.properties`.

]()[

Architecture

In order to refine the ORS configuration, it is essential to understand its core architectural elements.

The ORS serves two key roles in the Marketcetera universe:

  1. It is an intermediary between ORS Clients (embedded within Photon, strategy agent, or other end-user applications) and brokerage firms. The connection to ORS Clients is effected by a mix of Web Services (WS) (for synchronous calls, such as broker status queries) and Java Messaging Services (JMS) (for asynchronous calls, such as optional notifications on broker status changes). The connection to brokers is effected by QuickFIX/J, which can, in fact, connect to any FIX-enabled counterparty; while these counterparties can, in general, be arbitrary intermediaries in financial transactions, the ORS refers to all of them as brokers.

  2. It is the gateway to the Marketcetera database for ORS Clients. That is, via WS calls, ORS Clients may obtain persistent data maintained by the ORS, e.g. past execution reports to populate Photon's history when it starts up.

Accordingly, each role has its own configuration, which we explore separately in later sections.

In addition, part of the ORS configuration requires an understanding of message flow through the ORS; in the context of the ensuing discussion, message refers to trading instructions or responses, and is not intended to encompass all the WS/JMS traffic in which the ORS participates. Messages are delivered to the ORS from either ORS Clients or from brokers:

]()[ ]()1. []()[Messages from ORS Clients are typically orders, cancellations, or replacements, which are intended for delivery to some broker. These messages are delivered to the ORS as either FIX Agnostic orders, or as escape-hatch FIX messages. The ORS chooses a broker for the message, using the ]()[broker selector](#selector), and then converts a FIX Agnostic order into a broker-specific FIX message. A [filter](#OrderFilter) is applied on the FIX message at that point (possibly leading to its rejection by the ORS), which is then modified by broker-specific [modifiers](#MessageModifier), [routes](#MessageRouteManager), and [pre-send (a.k.a. send-only) modifiers](#PreSendMessageModifier). The altered message is then sent to QuickFIX/J for delivery to a broker while the ORS persists and then sends an immediate ack to the appropriate ORS Clients (`PENDING_xxx`, where `xxx` is the desired operation such as `NEW`, `CANCEL`, or `REPLACE`).
  1. In due time (though, rarely, before even the ORS can issue its immediate ack), the broker issues one or more formal responses; these are usually execution reports, such as a formal ack that an order was received, followed by a series of fills. Such messages from brokers, as well as most other messages received from brokers, are first filtered (which may lead to rejection of the broker's message), modified by broker-specific response modifiers, and then routed to the ORS Clients.

The above is a rough outline of the ORS message flow. There are a number of special cases and refinements (such as the generation of rejections) that are beyond the scope of regular use and are not covered here.

[

Web services

The ORS WS configuration comprises the following settings:

  • The WS hostname and port on which the ORS listens for WS requests, usually `localhost` and `9000`, respectively.

    Spring `SpringConfig.serverHost` `server.xml`
    Properties `metc.ws.host`
    Spring `SpringConfig.serverPort` `server.xml`
    Properties `metc.ws.port`

  • The time interval, in seconds, during which the ORS must receive a heartbeat from ORS Client (who sends one heartbeat every 5 seconds), or else the client's session is unilaterally terminated by the ORS. This automatic termination prevents all future WS calls from completing, results in rejection of all subsequent orders delivered via JMS, and the ORS Client receives no further messages from the ORS. That is usually `300` (5 minutes), or `-1` (a sentinel value that disables unilateral session termination).

    Spring `SpringConfig.serverSessionLife` `server.xml`
    Properties `metc.ws.session.life`
]()[

JMS services

]()

The ORS interacts with JMS services in two distinct ways: it contains an embedded JMS broker, and also acts as a JMS producer/consumer.

The default configuration of the ORS uses Apache's ActiveMQ for all JMS services (the broker, as well as the producer/consumer connection factories), but that can be changed by altering the Spring configuration files mentioned below.

[

JMS broker

By default, the JMS broker is configurable via a minimal set of properties: the name of the JAAS configuration file containing the JAAS authentication domain `ors-amq-domain`, used by the broker to authenticate producer/consumer connections, and the URL on which the broker listens for standard (TCP) connections.

Spring `BrokerService` `messaging/broker.xml`
Properties `java.security.auth.login.config`
Properties `metc.jms.broker.url`
]()

In default.properties, the WS host metc.ws.host is used to define metc.jms.broker.url; the WS host is also used in messaging/broker.xml to define the URL on which the broker listens for Stomp connections. By default, java.security.auth.login.config points to messaging/login.config. Detailed configuration of the broker is possible via the properties of the BrokerService bean, as well as via the URL's TCP transport options.

JMS producer/consumer

[

As a JMS producer/consumer, the ORS is configured with an incoming and an outgoing factory for JMS connections.

Spring `SpringConfig.incomingConnectionFactory` `server.xml`
Spring `ActiveMQConnectionFactory` `messaging/client.xml`
Spring `SpringConfig.outgoingConnectionFactory` `server.xml`
Spring `PooledConnectionFactory` `messaging/client.xml`

The factories rely on two Spring beans, named `runtimeUsername` and `runtimePassword`, for the JMS broker authentication credentials used by the ORS in its role as JMS producer/consumer. These beans are defined at run-time by the ORS, which obtains the credentials from properties (below), the command-line (via the `-u` and `-p` switches), or the console. By default, the credentials come from the following properties:

Properties `metc.amq.user`
Properties `metc.amq.password`

However, they may be overridden on the ORS command-line; or, their definitions in the property files can be removed (or commented out), in which case the ORS will either look for the credentials on the command-line, or, if absent, will prompt for them on the console. This run-time resolution of authentication credentials requires that the list of properties files be defined in a bean named `propertiesFiles` (by default, this bean is defined in `properties.xml`).

]()

Detailed configuration of the producer/consumer connection factories is possible via the properties of the beans above: ActiveMQConnectionFactory and PooledConnectionFactory.

[

Brokers

The ORS broker configuration has multiple parts:

]()[ ]()

  • The QuickFIX/J configuration of the brokers, which is two-level: QuickFIX/J session settings that apply to all brokers, and QuickFIX/J session descriptors that apply to each broker (and may override the session settings). Also, alongside the QuickFIX/J configuration, some additional non-QuickFIX/J configuration takes place (such as setting broker names and IDs).

  • The configuration of filters, some of which apply to all brokers, and some which are broker-specific.

  • The broker selector, which chooses a broker to direct incoming orders (for those orders that have no explicit broker), reaching the ORS from ORS Clients. The selector is most useful in the context of multiple brokers.

[

QuickFIX/J

These beans respectively set the brokers' QuickFIX/J session settings, and the per-broker QuickFIX/J session descriptor:

Spring `SpringSessionSettings.defaults` `brokers/qsettings.xml`
Spring `SpringSessionDescriptor.dictionary` `brokers/broker/qdescriptor.xml`
]()

In both cases, the property value is a map, whose property names and values are defined by the standard QuickFIX/J configuration.

In general, the per-broker session descriptor inherits the property name-value pairs of the session settings. However, two additional pseudo-properties may be defined only in the session settings:

QuickFIX/J pseudo-property `metc.LogFactoryClass` `quickfix.SLF4JLogFactory` (default)

quickfix.FileLogFactory

quickfix.JdbcLogFactory

quickfix.ScreenLogFactory
QuickFIX/J pseudo-property `metc.MessageStoreFactoryClass` `quickfix.FileStoreFactory` (default)

quickfix.JdbcStoreFactory

quickfix.SleepycatStoreFactory

Also, the standard session descriptor property DataDictionary (possibly inherited from session settings) may be assigned the pseudo-value metc.DefaultDataDictionary which enables validation using the default QuickFIX/J data dictionary appropriate for the descriptor's FIX version.

For the end-user's convenience, the default configuration files relegate the most common QuickFIX/J properties into these regular properties (the QuickFIX/J properties are shown on the third column):

Properties `metc.broker.qf.begin.string` `BeginString`
Properties `metc.broker.qf.data.dictionary` `DataDictionary`
Properties `metc.broker.qf.sender.comp.id` `SenderCompID`
Properties `metc.broker.qf.target.comp.id` `TargetCompID`
Properties `metc.broker.qf.store` `FileStorePath`
Properties `metc.broker.qf.host` `SocketConnectHost`
Properties `metc.broker.qf.port` `SocketConnectPort`

The QuickFIX/J settings are coupled to some non-QuickFIX/J settings in both the session settings and descriptor via these bean properties:

Spring `SpringBrokers.settings` `brokers/main.xml`
Spring `SpringBroker.descriptor` `brokers/broker/main.xml`

The per-broker non-QuickFIX/J settings include additional properties: the broker's name and id, which are both arbitrary strings (the ID is best kept short), and filters.

Spring `SpringBroker.name` `brokers/broker/main.xml`
Properties `metc.broker.name`
Spring `SpringBroker.id` `brokers/broker/main.xml`
Properties `metc.broker.id`

Finally, the individual SpringBroker beans are coupled to the SpringBrokers bean via this bean property:

Spring `SpringBrokers.brokers` `brokers/main.xml`

[

Filters

There are several filters that may be applied to traffic that goes through the ORS; no filters are activated in the default configuration.

]()[ ]()[ ]()

  • An instance of the OrderFilter interface may be applied to every message received by the ORS from ORS Clients (regardless of broker), after it has been translated into a broker-specific FIX form but before message modifiers and routes are applied; if it rejects the message (its assertAccepted() method throws a CoreException), the ORS rejects the message in turn (and does not forward it to the broker).

    Spring `SpringConfig.allowedOrders` `server.xml`
    Spring `OrderLimitFilter` `filters/allowed_orders.xml`

    A common choice for such a filter is OrderLimitFilter which specifies a set of order limits (minimum and maximum price, maximum quantity, and maximum notional); these checks are performed only if both the limit is set (i.e. non-null) and the message contains the relevant data (price, quantity, or both). In addition, the same filter can optionally reject market orders.

    Spring `OrderLimitFilter.minPrice` `filters/allowed_orders.xml`
    Spring `OrderLimitFilter.maxPrice` `filters/allowed_orders.xml`
    Spring `OrderLimitFilter.maxQuantityPerOrder` `filters/allowed_orders.xml`
    Spring `OrderLimitFilter.maxNotionalPerOrder` `filters/allowed_orders.xml`
    Spring `OrderLimitFilter.disallowMarketOrders` `filters/allowed_orders.xml`

    The sample configuration of this filter is not enabled by default (the setting of the allowedOrders property is commented out).

  • A sequence of MessageModifier implementations (in a list value that is assigned to the messageModifiers property of the MessageModifierManager bean) may be applied to every message received by the ORS after the destination broker has been selected but before the routes are applied. This filter is specific to each broker.

    Spring `SpringBroker.modifiers` `brokers/broker/main.xml`
    Spring `MessageModifierManager.messageModifiers` `brokers/broker/modifiers.xml`
    Spring `DefaultMessageModifier` `brokers/broker/modifiers.xml`

    A common choice for such a modifier is DefaultMessageModifier which specifies zero or more modifications to message header, body, and trailer fields that match a particular pattern. For each category, a map of modifications is assigned, and each modification has a key, which selects a field to be modified (possibly in some limited contexts only), and the value to which the field is set. The field selection can be as simple as a field tag alone, or a field tag followed by a context in parentheses; the context can be app (for all application messages), admin (for all session messages), * (for all messages; same as if no context is specified), or a letter/digit (for messages of that specific message type). So, for example, the modification keys 50 or 50(*) with associated value mySenderSubID always add the SenderSubID field (whose tag is 50) equal to mySenderSubID into every message, while 50(A) adds it only to the Logon message.

    Spring `DefaultMessageModifier.headerFields` `brokers/broker/modifiers.xml`
    Spring `DefaultMessageModifier.msgFields` `brokers/broker/modifiers.xml`
    Spring `DefaultMessageModifier.trailerFields` `brokers/broker/modifiers.xml`

    The sample configuration of this filter is not enabled by default (the setting of the modifiers property is commented out).

  • An instance of the MessageRouteManager class may be applied to every message received by the ORS after the destination broker has been selected and the message modifiers have been applied. This filter is specific to each broker.

    Spring `SpringBroker.routes` `brokers/broker/main.xml`
    Spring `MessageRouteManager` `brokers/broker/routes.xml`

    The filter's intent is to translate incoming symbols that include routing information (separated by .) into outgoing symbols without that information, while encoding the routing portion into FIX fields dedicated to such routing; note that such routing is effected by the broker and is wholly independent of the ORS's broker selection. The choice of the field that will contain the routing information can be either field:57 (using the TargetSubID header field), field:100 (using the ExDestination body field), or field:128 (using the DeliverToCompID header field). A map pairs up the routing suffixes to values placed in the routing information field; for example, the entry key-value of (N,SIGMA) will translate a symbol such as IBM.N to IBM and set the routing information field to SIGMA.

    Spring `MessageRouteManager.routeMethod` `brokers/broker/routes.xml`
    Spring `MessageRouteManager.routes` `brokers/broker/routes.xml`

    In addition to this core filtering, this filter can also split an incoming symbol into an outgoing Symbol field and an outgoing SymbolSfx field. This optional adjustment applies only to non-FOREX orders; the / character should be used within the incoming symbol to separate the symbol and suffix.

    Spring `MessageRouteManager.separateSuffix` `brokers/broker/routes.xml`

    The sample configuration of this filter is not enabled by default (the setting of the routes property is commented out).

[

  • An instance of the `MessageFilter` interface may be applied to every application message received by the ORS from any broker, and if it rejects the message (its `isAccepted()` method returns false), QuickFIX/J is notified of the rejection.

    Spring `SpringConfig.supportedMessages` `server.xml`
    Spring `MessageTypeFilter` `filters/supported_messages.xml`

    A common choice for such a filter is `MessageTypeFilter` which accepts a message if its type is within a given set of messages types. The acceptable types are all listed in a set; messages without a type can be accepted or rejected.

    Spring `MessageTypeFilter.acceptedMessages` `filters/supported_messages.xml`
    Spring `MessageTypeFilter.acceptUnknown` `filters/supported_messages.xml`

    The sample configuration of this filter is not enabled by default (the setting of the `supportedMessages` property is commented out).

    • ]()[ ]()

    MessageModifierManager

    The MessageModifierManager bean is part of several filters, as noted above. It is possible for advanced users to replace the provided MessageModifierManager with a subclass that overrides the

    public void modifyMessage(RequestInfo info)
    throws I18NException

    method of MessageModifierManager. Consult the javadoc of the RequestInfo class (and its package javadoc) for additional insights on the information being made available to the above method. Note that the above method can even go as far as replacing the current QuickFIX/J message with another, completely different, message.

    [

    Broker selector

    The broker selector object configures the broker selection algorithm.

    Spring `SpringConfig.selector` `server.xml`
    Spring `SpringSelector` `brokers/selector.xml`

    The selector comprises an ordered list of selector entries (instances of `SpringSelectorEntry`), and a default broker (a bean reference to the appropriate `SpringBroker` bean). Both are optional.

    Spring `SpringSelector.entries` `brokers/selector.xml`
    Spring `SpringSelector.defaultBroker` `brokers/selector.xml`

    Broker selection works as follows:

    1. If the incoming order has a broker ID, use the broker with that ID, and conclude the broker selection.

    2. Otherwise, go down the list of selector entries (if any) until a matching entry is found: a matching entry is one whose required security type (a string such as `CS` for Common Stock or `OPT` for options) matches that of the order.

      Spring `SpringSelectorEntry.targetType` `brokers/selector.xml`

      If the entry's required broker (a bean reference to the appropriate `SpringBroker` bean) is available (online), then use that broker and conclude the broker selection.

      Spring `SpringSelectorEntry.broker` `brokers/selector.xml`

      If it is not available, then: if the entry's optional `skipIfUnavailable` flag is true, skip that entry and continue the search for a matching entry.

      Spring `SpringSelectorEntry.skipIfUnavailable` `brokers/selector.xml`

      Otherwise, if the entry's `skipIfUnavailable` flag is false (or missing), reject the order (and conclude the broker selection).

    3. If there is no match, use the default broker (which implies rejection and conclusion of the broker selection if that broker is unavailable). And if there is no default broker, reject the order (and conclude the broker selection).

    This selection algorithm supports several common scenarios:

    • No list; no default broker. All orders are required to specify a broker.

    • No list; the default broker is set to the one and only broker defined in the ORS. Thus, no orders need to carry an explicit broker, and the one system broker (the primary broker) is where all orders go. This is the default configuration.

    • A list where all common stock orders are directed to one broker and all option orders are directed to another broker; no default broker. This is a simple scenario where the same broker is always used for each security type.

    • A list where all common stock orders go to broker A, if available, and broker B otherwise (i.e. there are two selector entries, both with the common stock security type, but the first has broker A and `skipIfUnavailable` set to true while the second has broker B and `skipIfUnavailable` set to false). Because broker A charges less than broker B, but is unreliable (or unavailable by design) during parts of the day, we want to select broker A for common stock orders, if possible, and broker B otherwise; if broker B is also unavailable, then the order is rejected.

    ]()[

    Multiple brokers

    A common alternative to the default configuration is to define multiple broker configurations. To this end, follow these steps:

    1. Rename the `brokers/broker` directory into `brokers/broker1`, and create a new directory `brokers/broker2`. Populate the new directory with files that mirror those of `brokers/broker1`. Similarly, you can create additional directories for more brokers.

    2. In the files inside each broker directory, specify the desired settings for each broker, incl. the QuickFIX/J session descriptor. You can either specify the settings in-line, or use new properties such as `metc.broker2.qf.begin.string`, `metc.broker2.qf.data.dictionary`, etc., relagating their values into `default.properties` or `user.properties` (and, while doing so, possibly replace the definitions as well as all uses of standard properties such as `metc.broker.qf.begin.string` with `metc.broker1.qf.begin.string`).

    3. Edit `brokers/main.xml` to import all the `brokers/broker*/main.xml` files, as well as add all the `SpringBroker` beans of all the brokers onto the list value of the `brokers` property of the `SpringBrokers` bean.

    4. Edit the selector's configuration to reflect your desired broker selection logic.

    ]()[

    Database services

    The database connection of the ORS is setup via

    Spring `ComboPooledDataSource` `db/db.xml`
    ]()

    This bean's properties can be further modified by the end-user.

    By default, this bean relegates its key settings to properties that define the class of the database JDBC driver, the credentials used to connect to the database, the size of the JDBC connection pool, and the JDBC connection URL.

    Properties `metc.jdbc.driver`
    Properties `metc.jdbc.user`
    Properties `metc.jdbc.password`
    Properties `metc.jdbc.pool.size`
    Properties `metc.jdbc.url`

    Also by default, an embedded MySQL database is used for database services. If the end-user decides to retain MySQL, the ORS connection to it can be configured by altering the URL property above (or edit the ComboPooledDataSource.jdbcUrl bean property directly).

    Again by default, the Java persistence implementation (object-relational mapper) the ORS uses is Hibernate. Both the choice of database and that of a persistence implementation can be changed via db/vendors.xml.

    Additional beans in support of the object-relational mapping are defined in db/orm.xml.

    One of the tasks carried out by the database is assisting in the generation of unique IDs (order IDs, execution IDs, etc.). The ID generation factory is set via the following Spring bean, and the default setting should suffice for most installations.

    Spring `SpringConfig.IDFactory` `server.xml`

    Another aspect of the database operations concerns storage and retrieval of historical data. This retrieval is made by default using a simple and relatively reliable synchronous provider; alternative providers, with different tradeoffs between performance and stability, can be composed and deployed by the end-user.

    Spring `SpringConfig.reportHistoryServices` `server.xml`

    Yet another aspect of the database operations is the caching mechanism used to associate orders with actor and viewer IDs. Multiple caching strategies are possible, and the default one provides a reasonable balance between memory usage and performance.

    Spring `SpringConfig.orderInfoCache` `server.xml`

    [

    Logging

    The ORS relies largely on SLF4J for logging, which in turn, by default, uses LOG4J; its configuration is stored in `log4j/server.properties` (the logging configuration of the CLI tool is in `log4j/cli.properties`). However, certain third party components embedded in the ORS may not use SLF4J or LOG4J for logging, and require configuration using their own custom mechanisms.

    While certifying a broker connection, the end-user may wish to change to `DEBUG` the logging level of some logging categories. The category

    Category `log4j.logger.org.marketcetera`

    will result in very verbose output (possibly excessively so). The category

    Category `log4j.logger.org.marketcetera.ors`

    will show detailed logs on all traffic exchanged between the ORS, ORS Clients, and brokers, and is probably best. If you want to include heartbeats in these detailed logs, these categories' logging levels should also be changed to `DEBUG` (the default for both is `ERROR`):

    Category `log4j.logger.org.marketcetera.ors.brokers.Broker.HEARTBEATS`
    Category `log4j.logger.org.marketcetera.ors.QuickFIXApplication.HEARTBEATS`
    ]()

    Another handy logging category reveals currently active sessions: if you want the ORS to report all active sessions whenever a change is made to them (or whenever the syncSessions() JMX call is made), change to DEBUG the category

    Category `log4j.logger.org.marketcetera.ors.UserManager`

    [

    JMX

    ]()

    Run-time JMX (MBeans) access is provided to the ORS, incl. its embedded components which support JMX: QuickFIX/J, ActiveMQ (the JMS implementation), C3P0 (the database connection pool), etc. The ORS itself provides two operations via JMX, namely:

    1. sendPasswordReset(), which changes the password used with a particular broker.

    2. syncSessions(), which re-reads the contents of the database and updates the current ORS sessions accordingly (i.e. removing sessions for deleted users, or adding/removing delivery rules for sessions whose associated user experienced a change in their superuser status).

    [

    Option Root Mapping

    ORS provides means to carry out mapping between option root symbol to its underlying symbol and vice-versa.

    ]()

    To enable ORS to carry out this function, the mapping file (in CSV format) should be downloaded from the OCC website and copied into the ORS installation. The ORS configuration should be updated to point to the mapping file location.

    The ORS mapping configuration comprises of the following settings.

    Spring `OptionRootUnderlyingMap.filename` `server.xml`
    Properties `metc.optionroot.map.file`
    Add a custom footer
    Add a custom sidebar
    Clone this wiki locally