Some conventions to follow for Diagnostic Provider (DP) Extensible
Markup Language (XML) declarations.
These guidelines are to help keep your use of Diagnostic Providers (DP)
consistent.
Some tips for configDump implementation
- configDump should contain information used to define the component's
environment. Some examples are:
- configuration data set by Java Management Extensions (JMX)
- configuration from system properties, xml files, and property files
- configuration information hard-wired and unchanging in code (such as,
if a resource adapter implements interface X, or has some static final field
Y, then those could indicate aspects of configuration and be included in the
configDump).
- configDump should not contain dynamically registered attributes, such
as:
- a list of registered loggers (this belongs in stateDump)
- a list of servlets in an application (this belongs in stateDump).
- configDump should be separated into 2 sections -- startup and current.
- All configDump attributes must start with either startup- or current-.
- The startup section details the component's environment at startup
time. Startup configDump attributes start with startup- .
- The current section details the component's environment at the
moment the configDump is requested. Current configDump attributes start with current-.
Best practices for configDump
- Group related attributes using an attribute hierarchy (such as, for two
attributes about the traceLog: startup-traceLog-rolloverSize=20, startup-traceLog-maxNumberOfBackupFiles=1)
- For information in the current attribute list that refers to the same
thing as a startup attribute, the names of both current and startup attributes
should match.
- If an attribute has no use after startup, only show it in the startup
section (for example, a configuration attribute that contains a file name
from which startup data is read).