Browse Prior Art Database

Automatic config annotation based on application Disclosure Number: IPCOM000236077D
Publication Date: 2014-Apr-04
Document File: 3 page(s) / 49K

Publishing Venue

The Prior Art Database


Automatically updating configuration files from a software runtime

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 50% of the total text.

Page 01 of 3

Automatic config annotation based on application

XML documents are commonly used to store configuration data for software applications and systems.

    As well as storing configuration data in XML it is also possible to add comments to the files to in order to annotate them with user-readable information about what the different parts of the file do and any information other developers might need.

    In most common use cases, XML files are written by users and read by applications. It is not common for applications to write information back into configuration files themselves.

    The idea described in this document is not specific to XML. It applies to software configuration files in any format.

    When a user is developing an application or system they might typically iterate through the following steps until their setup is correct:

    1) Create/modify the configuration file with config data 2) Start the application 3) View the error logs for any errors that have arisen through misconfiguration

    4) Go back to step 1 and repeat until the application operates correctly. The idea described in this document is to combine steps 1) and 3) to allow them to be performed more easily. When the application starts and encounters a problem, instead of writing error information to a specific log file the application annotates the XML file with comments describing the problems that have occurred and, ideally, suggested solutions.

    Configuration settings are used and checked in two places. Hence there are two places at which software may write information to a log file and two subtly different algorithms for each one. This idea applies primarily to the first of these two options. However, the second option may be useful in certain circumstances and hence is included in the disclosure for completeness.

1) When the file is initially parsed.

    If the basic validation of the configuration file fails, information is written to logs to indicate the problem(s). In many cases the information passed back to the user can be quite specific. For example, if an IP address field must follow a specific format and the value provided by the user doesn't match that fit the required pattern, the application can tell the user that their IP address is incorrectly formatted.

    Our idea uses the following algorithm to annotate the configuration file instead of writing to the logs:

Reopen the configuration file

Locate the element known by the application to be incorrectly formatted Check if a user comment already exists for this element, and if it does remove it (see note later on as to why we do this)

Insert a new entry in the DOM before that element, and insert a user comment (following the syntax required by the particular file format) describing the error identified by the application
Close the file
2) When particular software components start and need to know how to

Page 02 of 3


This case is more complicated. Many configuration options are only used if the components they apply...