Configuration

InPUT uses itself for configuration. Features, such as logging and injection can be activated by the user, and are active if the required modules are setup in the classpath. This tutorial shows how the configuration can be customized and get accessed in the code.

1. config.xml

The following table shows the customizable configuration features for InPUT:

Feature	Description
evaluator	The evaluator implementation that is used for the relative inter-parameter range definitions for numeric parameters. Currently, the javascript engine is used by default.
random	The randomizer implementation that is used by InPUT for the random drawings. By default, this is java.util.Random
threadSafe	Supposed to ensure thread safety among experiments, designs, and design spaces. Not supported yet.
logging	Enables/Disables the logging and stores it in "input.log" if the logging module is in the classpath and AspectJ activated.
injection	Enables/Disables the injection-based description of parameter input/output if the injection module is in the classpath and AspectJ activated.
runtimeValidation	Ensures that the xml files are validated and offers reasonable exception handling and failure messages, with a small penalty on performance.
schemaPath	The path where the schema files (Design.xml, DesignSpace.xml, and CodeMapping.xml) are searched for. If no internet connection is available, or no soft link to a local copy been established, this is a way to make InPUT work offline.
cacheDesigns	If enabled, all designs that are created in the code are made available via lookup using the static Design.lookup(designId : String) method.

config.xml, configSpace.xml, and configSpaceMapping.xml can be found in the se.miun.itm.input package of the InPUT4j core module, and can be customized by the user.

The identifiers in the config.xml are booked and should not be reused in any design space definition. We therefore encouraged the use of parameter identifiers with a capital first letter (e.g. "ParamId" instead of "paramId").

2. InPUTConfig

At times, knowing if a feature is turned on in the configuration can have an impact on the implementation that uses InPUT. InPUTConfig is an abstract class offering static access to the configuration values. Amongst others, it offers the following functions:

• isLoggingActivated()
• isInjectionActive()
• getValueToString(paramId : String)
• getValue(paramId : String)

The getValue function gives direct access to config.xml. There is even a setValue(paramId: String, value : Object), of which the use is discouraged.

3. Reusing Configuration

InPUT configuration can directly be used from within the code, or referred to in the code mapping. The randomizer for instance can be retrieved through any design as in

Random rng = myDesign.getValue("random");

for simplicity reasons. However, this is read only, and a write will result in an exception to be thrown.

Alternatively, the randomizer could be a formal parameter for a code mapping constructor. Given that a mapping has two parameters, the constructor definition could look as such

<Mapping id="MyParam" type="my.Type" constructor="random AnotherParam"/>

and will use the actual randomizer instance as actual parameter for the instantiation of the MyParam object.

Summary

In this tutorial you learned where to find the InPUT meta-configuration file, and how to change its parameter settings. You further got to know features for making the configuration available both, through code, and within code mappings, for reasons of reusability.