Extensible Markup Language des Diagnoseproviders
Im Folgenden werden verschiedene Konventionen für die XML-Deklarationen (Extensible Markup Language) von Diagnoseprovidern (DP) beschrieben.
Die folgenden Richtlinien helfen Ihnen, bei der Verwendung von Diagnoseprovidern (DP)
konsistent zu bleiben.
- Fügen Sie die Dokumenttypdefinition (DTD, Document Type Definition) für Ihren Diagnoseprovider am Anfang jeder DP-XML-Deklarationsdatei ein.
- Beginnen Sie alle Namen und Namenssegmente mit einem Kleinbuchstaben. Verwenden Sie für Attributnamen den so genannten Kamelstil, d. h. verwenden Sie für jeden Anfangsbuchstaben im Namen mit Ausnahme des ersten einen Großbuchstaben, z. B. traceCollectionSpec.
- Verwenden Sie für die Kennzeichnung der Hierarchie Minuszeichen. Minuszeichen eignen sich besser als Punkte, da Attributnamen reguläre Ausdrücke sind, z. B. traceService-traceCollectionSpec.
- Geben Sie Teile mit dynamischen Zeichenfolgen für Attributnamen mit einem Stern (*) an. Beispiel:
vhosts-.*-webgroups-.*-webapps-.*-listeners-filterInvocationListeners
Eine Entsprechung hierfür wäre vhosts-einHost-webgroups-eineGruppe-webapps-eineAnwendung-listeners-filterInvocationListeners - Geben Sie Teile mit dynamischen numerischen Zeichen für Attributnamen mit [0-9]* an,
z. B.:
Beispiel:
vhosts-index-[0-9]*
Eine Entsprechung hierfür wäre webcontainer-vhosts-index-123 - Wenn Sie einen allgemeinen Selbstdiagnosetest haben, der ohne erhebliche Leistungseinbußen ausgeführt werden kann, nennen Sie ihn general.
Tipps für die configDump-Implementierung
- configDump sollte Informationen enthalten, die für die Definition der Komponentenumgebung verwendet werden. Beispiele:
- Konfigurationsdaten, die von Java™ Management Extensions (JMX) definiert werden,
- Konfigurationsdaten aus Systemeigenschaften, XML-Dateien und Eigenschaftendateien,
- unveränderliche Konfigurationsdaten, die sich im Code nicht ändern (wenn ein Ressourcenadapter beispielsweise die Schnittstelle X implementiert oder ein "static final"-Feld Y enthält, können dies Konfigurationsaspekte sein, die in den configDump aufgenommen werden sollten).
- configDump sollte keine dynamisch registrierten Attribute enthalten, wie z. B.:
- Liste registrierter Protokollfunktionen (Logger). Diese Informationen gehören in einen stateDump.
- Liste von Servlets in einer Anwendung. Diese Informationen gehören in einen stateDump.
- configDump sollte in zwei Abschnitte unterteilt werden -- startup und current.
- Alle configDump-Attribute müssen mit startup- oder current- beginnen.
- Der Abschnitt startup enthält ausführliche Informationen zur Umgebung der Komponente zur Startzeit. Die Startattribute eines configDump beginnen mit startup-.
- Der Abschnitt current enthält ausführliche Informationen zur Umgebung der Komponente zum Zeitpunkt der configDump-Anforderung. Aktuelle Attribute des configDump beginnen mit current-.
Empfohlene Methoden für configDump
- Gruppenbezogene Attribute, die eine Attributhierarchie verwenden (z. B. die beiden traceLog-Attribute startup-traceLog-rolloverSize=20, startup-traceLog-maxNumberOfBackupFiles=1)
- Für Informationen in der Liste der aktuellen Attribute, die sich auf dasselbe wie ein Startattribut beziehen, sollten die Namen von aktuellem Attribut und Startattribut übereinstimmen.
- Wenn ein Attribut nach dem Start nicht mehr verwendet wird, sollte es nur im Abschnitt startup erscheinen (z. B. ein Konfigurationsattribut, das den Namen einer Datei enthält, aus der die Startdaten gelesen werden).