Etiquetas doTag en Java JSP

 Las siguientes líneas dentro de doTag proporcionan la implementación para escribir en la salida JSP a través de una serie de llamadas a out.println. Cualquier contenido que se pase a out.println se mostrará en la página. Tenga en cuenta que en el ejemplo,
se comprueba el campo
para ver si contiene un valor nulo. Si no contiene un valor nulo, entonces
se muestra en la página; de lo contrario, se omite. Por lo tanto, si la etiqueta dentro de la página JSP contiene un valor para el atributo authorName, se imprimirá en la página. El código out.println está contenido dentro de un bloque try-catch en caso de que ocurra alguna excepción.
■ Nota Para permitir que su etiqueta acepte scriptlets, deberá utilizar los controladores de etiquetas clásicos. Los controladores de etiquetas clásicos existían antes de la era JSP 2.0 y todavía se pueden utilizar junto con los controladores de etiquetas simples. Los controladores de etiquetas simples giran en torno al método doTag (), mientras que los controladores de etiquetas clásicos se ocupan de un método doStartTag () y un método doEndTag (), entre otros. Dado que los controladores de etiquetas simples se pueden utilizar junto con los controladores de etiquetas clásicas, es posible utilizar algunos de los métodos de etiquetas clásicas más complejos, al mismo tiempo que se utilizan métodos de etiquetas simples en la misma aplicación. Esto facilita la transición de los controladores de etiquetas clásicos a los controladores de etiquetas simples. Para obtener más información sobre las diferencias entre los dos aPI, consulte la documentación en línea mediante la búsqueda de las palabras clave Controladores de etiquetas simples y clásicos.
Eso es todo; la implementación de la etiqueta está completa. Para asignar la clase de implementación al Modelo de objetos de documento (DOM) a través de un nombre de etiqueta, un TLD debe contener una asignación a la clase. En el ejemplo, se crea un TLD llamado custom.tld y contiene el mapeo de la clase. El elemento short-name especifica el nombre que debe ser
utilizado dentro de la página JSP para hacer referencia a la etiqueta. El elemento uri especifica el nombre del TLD y se utiliza desde la página JSP para hacer referencia al archivo TLD en sí. La carne del TLD está contenida dentro del elemento de etiqueta. los
El elemento de nombre se usa para especificar el nombre de la etiqueta, y se usará dentro de una página JSP en combinación con el elemento de nombre corto para proporcionar el nombre de etiqueta completo. El elemento tag-class proporciona el nombre de la clase que implementa la etiqueta, y body-content especifica un valor para indicar si el contenido del cuerpo de la página JSP estará disponible para la clase de implementación de la etiqueta. Está configurado como vacío para este ejemplo. Para especificar un atributo para la etiqueta, el elemento de atributo debe agregarse al TLD, incluido el nombre, rtexprvalue y los elementos requeridos. El elemento name del atributo especifica el nombre del atributo, rtexprvalue indica si el atributo puede contener una expresión EL y required indica si el atributo es obligatorio.

Archivo de configuración rndc.conf

Primero veamos la configuración del comando rndc. La configuración del comando rndc se controla en dos lugares: en el archivo de configuración rndc.conf y mediante controles y declaraciones clave que necesita agregar al archivo de configuración named.conf.

El archivo de configuración rndc.conf contiene las opciones de configuración que especifican cómo el comando rndc se conecta al demonio nombrado. Este archivo también contiene un hash criptográfico, como el que usa TSIG (ver la sección “TSIG”), que autentica el comando en el canal de control. La declaración de controles en el archivo named.conf especifica las opciones para configurar el canal de control al que se conecta el comando rndc, y la declaración clave del archivo named.conf contiene una copia del hash criptográfico especificado en el archivo rndc.conf. Definido tanto en la configuración del comando rndc como en la configuración del servidor BIND, el hash criptográfico actúa como un secreto compartido. 

De forma predeterminada, el archivo rndc.conf se encuentra en / etc. Si ha chrooteado el demonio nombrado, necesita crear un enlace simbólico al archivo en la cárcel chroot; por ejemplo, usando la cárcel chroot creada en la sección "Chrooting BIND", crearía el enlace simbólico en el directorio / chroot / named / etc

El archivo rndc.conf puede contener tres tipos de instrucciones: opciones, servidor y clave. Estas sentencias usan la misma sintaxis que las sentencias named.conf, y todas deben terminar con punto y coma.
La primera declaración, opciones, especifica los valores predeterminados del comando rndc.

El servidor se puede especificar por dirección IP o nombre de host. Para la declaración d
el servidor, he especificado la dirección IP del host local 127.0.0.1. Para cada declaración de servidor, también debe especificar la clave que se utilizará para este servidor. Puede hacer esto usando la subenunciación clave.

BIND - Vistas Parte 2

 Las vistas deben tener un nombre y debe colocar el nombre entre comillas para permitir el uso de cualquier nombre, incluidas las palabras de configuración BIND protegidas. Para ello hemos definido una vista llamada interna. Después del nombre de la vista, he especificado su clase, IN. Esta es la clase de Internet y debería usarse para casi todas las vistas. Si no especifica una clase, BIND se establecerá de forma predeterminada en una clase de IN. Finalmente, el contenido de la vista está incluido entre llaves, y la última llave debe terminar con un punto y coma, en línea con el estilo estándar de instrucción de configuración named.conf.

La declaración de vista tiene tres secciones principales: las opciones de coincidencia del cliente, las opciones de vista y las zonas definidas en esta vista. La opción de coincidencia de clientes es necesaria para todas las vistas y, para ello, especifico la subenunciación de coincidencias de clientes. Esta sub-declaración le permite especificar los clientes particulares que pueden usar esta vista. Debe especificar esta subdeclaración para asegurarse de que la vista coincida con clientes particulares. En la subenunciado match-clients, he especificado un acl, de confianza, anteriormente en este capítulo. Esto configura BIND para que coincida con todas las direcciones especificadas en ese acl con esta vista. La opción match-clients también puede usar los parámetros normales de la lista de coincidencias de direcciones BIND, como direcciones IP, redes o claves.

También puede especificar una subenunciación de coincidencia de cliente adicional, destinos de coincidencia. La subdeclaración de destinos coincidentes le permite hacer coincidir los clientes por el destino al que se han conectado. También puede usar estas dos sub-declaraciones juntas para hacer coincidir el origen y el destino de un cliente.
Por último, también puede especificar la subenunciación solo recursiva de coincidencia, que indica que solo las consultas recursivas de clientes coincidentes se compararán con la vista. Otros tipos de consultas no coincidirán con la vista.