Me retiro del desarrollo de Software

 Apreciable audiencia

Me retiro del desarrollo de Software, ahora me voy a dedicar a las Inversiones y Trading, si quieres seguirme puedes suscribirte a mi canal

https://www.youtube.com/@eltradermexicano

Mapear XML a Objetos en Java

 En Java tenemos al menos dos FrameWorks para mapear objetos de XML a Java y viceversa. El primero es XML Beans y el segundo es Eclipse Modeling Framework (EMF). Aclaro que no soy muy fan de Eclipse y en esta entra no voy a entrar en detalles.

Mapear XML a Objetos usando EMF

Esta entrada no está muy detallada, no soy fan de Eclipse así que solo lo revisaremos de forma muy superficial.

Instalación de los plugins

Generando el Jar con Objetos

Java RMI

En el sentido más amplio, "RMI" está vivo y bien: hay muchas aplicaciones en las que un proceso expone métodos para ser ejecutados por otro. La situación es ligeramente diferente cuando el término se usa para referirse al método patentado de RMI que está integrado en la JVM y ha existido desde los primeros días de Java. Este método de RMI utiliza un protocolo que es bastante específico de Java, no tiene soporte incorporado para propagar un contexto de transacción o un contexto de seguridad, y es complicado de enrutar a través de firewalls. Puede usar el mismo marco RMI en Java con protocolos como IIOP, que son independientes del idioma y admiten la propagación del contexto de seguridad y transacciones; pero todavía hay problemas con los firewalls.

La tecnología RMI de Java tradicional todavía se usa ampliamente para la administración y el monitoreo remotos, pero no veo que se use mucho a nivel de aplicación. Parece más popular en estos días exponer métodos como servicios web e invocarlos usando HTTP(S). Hay marcos para hacer esto en Java, y dichos servicios pueden hacerse independientes del idioma.

Este tutorial está diseñado y probado para Java 8, veremos de repaso algunos temas que ya están deprecados y que difícilmente podremos llevarlo a la practica.

Un resumen de las aplicaciones RMI

Las aplicaciones RMI a menudo se componen de dos programas, un programa servidor y un programa cliente. Un programa servidor crea objetos remotos, permite que puedan ser referenciados y espera para que otros programas clientes invoquen los métodos de estos objetos. Un programa cliente obtiene referencias remotas de uno o mas objetos que se encuentran en el servidor y entonces invoca los métodos de estos.

RMI proporciona el mecanismo por el cual el servidor y el cliente se comunican y pasan información de un lado a otro. Tal aplicación a veces se denomina aplicación de objetos distribuidos.

Los objetos de las aplicaciones distribuidas necesitan realizar lo siguiente:

• Localizar objetos remotos. Las aplicaciones pueden usar varios mecanismos para obtener referencias de objetos remotos. Por ejemplo, una aplicación puede registrar objetos remotos con el registro RMI RMI's simple naming facility. Alternativamente, una aplicación puede pasar y retornar referencias de objetos remotos como parte de otras invocaciones remotas.
• Comunicarse con objetos remotos. Detalles de la comunicación entre objetos remotos son manejados por RMI. Para el programador, la comunicación remota parece similar a una invocación regular de métodos Java.
• Cargar definiciones de clases para los objetos que se pasan. Porque RMI habilita que os objetos se pasen de un lado a otro, proporciona mecanismos para cargar la definición de clase de un objeto así como también mecanismos para la transmisión de datos del objeto.

La siguiente ilustración representa una aplicación distribuida RMI que usa el registro RMI para obtener una referencia a un objeto remoto. El server invoca el nombre del objeto remoto registrado. El cliente busca el objeto remoto por el nombre con el que se registro en el servidor y luego ejecuta los metodos. La ilustración también muestra que el sistema RMI usa un servidor web para cargar las definiciones de clases, desde el servidor hacia el cliente y desde el cliente hacia el servidor, para los objetos cuando sean requeridos.

Como administrar tu lista de tareas TODO en Netbeans

 Es común que mientras estás codificando van surgiendo tareas que se derivan de la tarea principal pero que no son prioritarios en el momento. Para que no te olvides puedes poner comentarios con el prefijo //TODO

Si eres un usuario recurrente de NetBeans ya estás enterado que a partir de la versión 8 o 9, NetBeans paso a formar parte de la fundación Apache y con ello muchos cambios vinieron.

Como administrar tu lista de tareas en NetBeans 13

El prefijo no necesariamente tiene que ser //TODO ya que lo puedes configurar a tu gusto, para ello debes ir a Tools - Team - Pestaña Action Items

Ahí puedes agregar patrones para TODO FIXME PENDING

Para ver las lista de estas tareas o comentarios debes activar el panel, para ello ve a Windows - Action Items

Java Logging API

Java Util Logger o jdk14logging  el API de Java Logging, se encuentra en el paquete java.util.logging, facilita el servicio de mantenimiento de software permitiendo generar reportes de logs para analizar errores, rendimiento o comportamiento del software.

Estos archivos son analizados por usuarios finales, administradores de sistemas, ingenieros de soporte técnico, y equipos de desarrollo de software.

El API de Logging captura información tales como fallas de seguridad, errores de configuración, cuellos de botella en el rendimiento, y o errores en la aplicación o plataforma.

El paquete principal incluye soporte para entregar texto plano o en formato XML como salida hacia la memoria, flujos de salida, consolas, archivos y sockets. Es más, el API de Logging tiene la capacidad de interactuar con otros servicios de Logging que ya existan en el sistema operativo.

Temas

• Vista general del Flujo de Control
• Niveles del Log
• Loggers
• Metodos del Logging
• Handlers
• Formatters
• El LogManager
• Archivo de configuración
• Configuración por defecto
• Actualizaciones dinámicas de configuración
• Métodos Nativos
• XML DTD
• Mensajes con ID's Unicos
• Seguridad
• Gestión de configuración
• Empaquetado
• Localización
• Acceso remoto y serialización
• Ejemplos de Java Logging
• Apéndice A: DTD para la salida XMLFormatter

Vista General del Flujo de Control

Las aplicaciones pueden generar logs invocando los métodos de objetos de la clase Logger. Los objetos de la clase Logger están organizados en jerarquía según el paquete de la clase (Abuelo - Padre - Hijo, y así sucesivamente). Los objetos Logger de una capa inferior pueden heredar algunas características de sus padres.

Estos objetos Logger crean objetos LogRecord que son pasados a objetos Handler para ser publicados. Ambos objetos, Logger y Handler pueden usar objetos Level y opcionalmente objetos Filter para decidir si ellos están interesados en un objeto particular de la clase LogRecord. Cuando es necesario publicar externamente un objeto LogRecord, un objeto Handler puede opcionalmente usar un objeto Formatter para localizar y formatear el mensaje antes de publicarlo en un flujo I/O.

Cada objeto Logger realiza un seguimiento de un conjunto de objetos Handler. Por defecto todos los objetos Logger también pueden enviar sus salidas a los objetos Logger padres. Pero los objetos Logger también podrían ser configurados para ignorar objetos Handler que estén arriba en la jerarquía.

Algunos objetos Handler pueden directamente enviar la salida a otros objetos Handler. Por ejemplo, el objeto de la clase MemoryHandler mantiene un buffer interno de objetos LogRecord, y por medio de eventos gatilladores, publica estos objetos LogRecord en otros Handler. En tales casos, cualquier formateo lo realiza el último Handler en la cadena.

Niveles de Log Logging Levels

Cada mensaje del log tiene asociado un objeto Level para el log. El Level  (Nivel) ofrece una guía de cuan importante y urgente es el mensaje del Log. Los objetos Level de un log encapsulan un valor entero, los valores mas altos indican prioridades más altas.

java.util.logging.Level define 7 niveles de logging

• SEVERE (el mas alto)
• WARNING
• INFO
• CONFIG
• FINE
• FINER
• FINEST

Hay otros dos niveles de logging, OFF que "apaga o ignora" todas las sentencias de logging y ALL que registra todas las sentencias de logging.

Te recomiendo probar todos los niveles de logging para que puedes comprender mejor su funcionamiento y prioridad.

Loggers

Como se indico anteriormente, un código cliente envía solicitudes de logs a objetos Logger. Cada objeto Logger realiza un seguimiento del nivel de registro que le interesa y descarta las solicitudes de registro que se encuentran por debajo de este nivel.

Los objetos Logger normalmente son entidades con nombres que utilizan nombres separados por puntos, como java.awt. Los nombres son jerárquicos (recuerda como las clases java se organizan en paquetes y directorios) y lo gestiona LogManager. Normalmente los nombres de estos Logger siguen el estándar de empaquetamiento de java, pero no es necesario que lo siga exactamente. Por ejemplo un Logger llamado java.awt podría manejar solicitudes de logging para clases que se encuentren en el paquete java.awt, pero también podría manejar solicitudes de logging para clases que se encuentren en sun.awt que soporten implementaciones de las abstracciones definidas en el paquete java.awt

Además de poder asignarle nombres a los objetos Logger, también es posible crear objetos Logger anónimos que no aparecen en el nombre de espacios compartidos.

Consulte la sección de seguridad.

Los objetos Logger mantienen un seguimiento de sus objetos Logger padres dentro del espacio de nombres. El padre de un Logger es su ancestro existente más cercano en el espacio de nombres. El objeto Logger raiz llamado "" no tiene padre. Todos los objetos Logger anonimos tienen como padre al objeto Logger raiz. Los objetos Logger pueden heredar varios atributos de sus padres en el espacio de nombres. En particular, un registrador puede heredar:

• El nivel del logging o Level Logging: Si el nivel de un logger se establece como null, entonces el logger usará un nivel effectivo que se obtendrá subiendo por el árbol de padres y usara el primer nivel no null.
• Handlers: De forma predeterminada un Logger registrará cualquier mensaje de salida en los handlers de sus padres y así recursivamente por el arbol.
• El nombre del Conjunto de Recursos Resource Bundle: Si un Logger tiene un nombre de Resource Bundle en null, entonces heredará el nombre de Resource Bundle de su padre y así recursivamente mientras sea null.

Handlers o Manejadores

Java SE proporciona las siguientes clases Handler:

• StreamHandler: Un simple handler para escribir registros formateados hacia un OutputStream.
• ConsonleHandler: Un simple handler para escribir registros formateados hacia un System.err.
• FileHandler: Un hanlder que escribe registros formateados en un solo archivo o en un conjunto de archivos logs que van rotando. Ya explicaremos más adelante a que nos referimos cuando decimos que van rotando.
• SocketHandler: Un handler que escribe registros formateados en puertos TCP/IP remotos.
• MemoryHandler:Un handler que almacena los registros en la memoria.

El archivo properties de configuración

Logging property	Description
handlers	A comma-delimited list of handler class names that are added to the root Logger. The default handlers are java.util.logging.FileHandler and java.util.logging.ConsoleHandler (with a default level of INFO).
java.util.logging.FileHandler.level	Sets the log level for all FileHandler instances. The default log level is FINE.
java.util.logging.FileHandler.pattern	The log file name pattern. The default is %t/edpLog%u%g.log which means that the file is named edpLog%u%g.log where: %u is a unique number to resolve conflicts between simultaneous Java processes. %g is the generation number to distinguish between rotating logs. %t specifies the system temporary directory as the location in which the log files are stored.
java.util.logging.FileHandler.limit	The maximum size of the file, in bytes. If this is 0, there is no limit. The default is 1000000 (which is 1 MB). Logs larger than 1MB roll over to the next log file.
java.util.logging.FileHandler.count	The number of log files to use in the log file rotation. The default is 10000 (which produces a maximum of 10,000 log files).
java.util.logging.FileHandler.formatter	The class name of the Formatter to use for the FileHandler instances.
java.util.logging.ConsoleHandler.level	Sets the default log level for all ConsoleHandler instances.
java.util.logging.FileHandler.append	Specifies whether the FileHandler should append onto any existing files (defaults to false).
java.util.logging.ConsoleHandler.formatter	The class name of the Formatter to use for the ConsoleHandler instances.
java.util.logging.SimpleFormatter.format	Specifies the format to use for log messages. For details on the format syntax, see: http://docs.oracle.com/javase/7/docs/api/java/util/logging/SimpleFormatter.html
com.oracle.eid = FINE com.oracle.endeca = FINE com.oracle.endeca.pdi = INFO	Sets the default logging level for the Big Data Discovery loggers.
org.eclipse.jetty = WARNING org.apache.spark.repl. SparkIMain$exprTyper = INFO org.apache.spark.repl.SparkILoop $SparkILoopInterpreter = INFO	Sets the default logging level for the Spark and Jetty loggers.

Referencia

https://jenkov.com/tutorials/java-logging/index.html

https://sematext.com/blog/java-logging/

https://docs.oracle.com/javase/7/docs/api/java/util/logging/SimpleFormatter.html

https://docs.oracle.com/cd/E57471_01/bigData.100/data_processing_bdd/src/rdp_logging_config.html

https://www.digitalocean.com/community/tutorials/logger-in-java-logging-example

https://commons.apache.org/proper/commons-logging/guide.html#Introduction

https://docs.oracle.com/en/java/javase/22/core/java-logging-overview.html