When the toolkit initializes, externalizers read all the definition files and store all the object definitions in memory in a tag structure. The externalizers exploit this structure to create different Java objects depending on the value of their definitions. This creates a problem when you must modify one of these memory definitions because you must stop the toolkit, make the modification to the appropriate definition file, and then restart and re-initialize the toolkit to implement the changes. This process may be acceptable in a development environment but there are other scenarios, such as a high-availability production environment, where you want to avoid the stop and re-initialize process.

The reset process allows you to make minor changes to the memory definitions in runtime. An example of a minor change is updating a self-defined processor when this change involves data or formats used only by this processor and cannot affect other processors. If you must make major changes that may affect the rest of the application, however, you should stop and re-initialize the toolkit. An example of a major change is changing generic definitions that may affect the overall system. Use the reset process with care and only when the changes affect a controlled atomic set of definitions.

When using the reset process, do the following to ensure that it works properly: