XML (Extensible Markup Language) de DP (Diagnostic Provider)
Algunos convenios que se han de seguir para las declaraciones XML (Extensible Markup Language) de DP (Diagnostic Provider)
Estas directrices le ayudarán a utilizar la coherencia de DP (Diagnostic Providers).
- Incluya la DTD (Document Type Definition) para el DP (Diagnostic Provider) al principio de cada archivo XML (Extensible Markup Language) de DP (Diagnostic Provider).
- Comience todos los nombres y segmentos de nombres con minúsculas. Utilice las mayúsculas iniciales de tipo camel case para los nombres de atributo. Esto es, escriba en mayúsculas la primera letra de cada nombre, excepto la primera letra. Por ejemplo, traceCollectionSpec.
- Indique la jerarquía con guiones. Los guiones funcionan mejor con puntos porque los nombres de atributos son expresiones regulares. Por ejemplo, traceService-traceCollectionSpec.
- Indique las partes dinámicas de la serie en los nombres de atributos con un asterisco (*). Por ejemplo,
vhosts-.*-webgroups-.*-webapps-.*-listeners-filterInvocationListeners
que debe coincidir con vhosts-someHost-webgroups-someGroup-webapps-someApp-listeners-filterInvocationListeners - Indique las partes dinámicas numéricas de los nombres de atributos con [0-9]*.
Por ejemplo,
vhosts-index-[0-9]*
que deben coincidir con webcontainer-vhosts-index-123 - Si tiene una prueba de autodiagnóstico de finalidad general que se puede ejecutar sin un coste de rendimiento importante, asígnele el nombre general.
Algunas sugerencias para la implementación de configDump
- configDump debe contener la información utilizada para definir el entorno del componente. A continuación
aparecen algunos ejemplos:
- conjunto de datos de configuración establecidos por JMX (Java™ Management Extensions)
- configuración de las propiedades del sistema, archivos xml y archivos de propiedades
- información de configuración en disco duro y que no se modifica en el código (como, por ejemplo, si un adaptador de recurso implementa la interfaz X o tiene un campo final estático Y, entonces puede indicar aspectos de la configuración y puede estar incluido en configDump).
- configDump no debe contener atributos registrados dinámicamente como, por ejemplo:
- una lista de registradores registrados (esto pertenece a stateDump)
- una lista de servlets de una aplicación (esto pertenece a stateDump).
- configDump se debe separar en dos secciones -- startup y current.
- Todos los atributos configDump se deben iniciar con startup- o current-.
- La sección startup describe detalladamente el entorno del componente durante el arranque. Los atributos configDump de arranque comienzan por startup-.
- La sección current describe detalladamente el entorno del componente cuando se solicita configDump. Los atributos configDump actuales comienzan por current-.
Métodos recomendados para configDump
- Atributos relacionados con el grupo que utilicen la jerarquía de atributos como, por ejemplo, dos atributos relacionados con traceLog: startup-traceLog-rolloverSize=20, startup-traceLog-maxNumberOfBackupFiles=1)
- Para obtener información acerca de la lista de atributos actual que hace referencia a lo mismo como un atributo de arranque, los nombres de los atributos actuales y de arranque deben coincidir.
- Si un atributo no se utiliza tras el arranque, sólo será necesario mostrarlo en la sección de arranque, por ejemplo, un atributo de configuración que contiene un nombre de archivo desde el que se leen los datos de arranque.