¿Cuál es el mejor patrón para usar el mismo registrador Log4net en muchos ensambles en una solución?

Question

Tengo una solución que consiste en una aplicación principal de winforms, con DLL de biblioteca de clases internamente asociadas desde las cuales deseo iniciar sesión. Este registro debe ser realizado por el mismo registrador, independientemente de si el cliente de UI principal o el dll asociado lo llama. El dll puede, por supuesto, ser utilizado por otras aplicaciones que tienen diferentes registradores en otras soluciones, pero en estas circunstancias tendrá una configuración log4net diferente y tal vez un conjunto diferente de complementos en total.

Un enfoque sería crear un singleton dentro de la aplicación principal y el registro de eso, sin embargo desde log4net es su propio singleton, que se puede referenciar siempre que pasemos la misma cadena (o tipo) a log4net.LogManager.GetLogger lo haremos iniciar sesión en el mismo destino (en mi caso, deseo utilizar un RollingFileAppender).

Esto funciona. Sin embargo, dado que el DLL tendrá varias clases, significaría que cada instancia de clase o clase estática a partir de la cual deseamos iniciar sesión requeriría i) un argumento que defina el nombre del registrador (para iniciar sesión en el mismo destino) y ii) en cada punto de entrada necesitaría llamar al log4net.LogManager.GetLogger(loggerName).

¿Cuál es el mejor patrón para usar aquí? ¿El enfoque correcto sería crear una instancia única en cada ensamblado? Mi preocupación aquí es que todavía tendremos que pasar el nombre del registrador a cada punto de entrada para el dll, lo que parece exagerado. Para evitar pasar el nombre del registrador, podría suponer que siempre es igual a System.Reflection.Assembly.GetCallingAssembly().GetName().Name.

Si esto es demasiado difícil para log4net, ¿hay otras soluciones más sencillas, como Enterprise Logging Block? ¿O es la mejor solución un enfoque de programación orientada a aspectos (AOP)?

Reference for anti-pattern approach for singleton here.

Answer 1

Casi un año después, pero yo pensaba que iba a contribuir de todos modos!

Basado en su comentario al post de Carl, creo que tal vez usted no entiende cómo funciona log4net. Sí, el loggername identifica el registrador. Sí, un registrador puede tener muchos apéndices. PERO, muchos registradores también pueden escribir en el MISMO appender. Por lo tanto, podría configurar los registradores "A", "B" y "C" a todos los registros en el archivo "X". Usted puede obtener los registradores de la siguiente manera:

ILog logger_a = LogManager.GetLogger("A"); 
ILog logger_b = LogManager.GetLogger("B"); 
ILog logger_c = LogManager.GetLogger("C"); 

Ahora, si inicia sesión con cualquiera de estos registradores, todos ellos pueden ir al mismo lugar (archivo "X") si se ha configurado de esa manera.

La ventaja de no usar el mismo nombre registrador a través de su aplicación es que se puede controlar el nivel de registro en diferentes lugares de su aplicación a través del archivo de configuración. Entonces, si el código que está utilizando los registradores "A" y "B" está funcionando bien, pero el código que está utilizando el registrador "C" está teniendo un problema, puede desactivar "A" y "B" y girar " C "todo el camino hacia arriba". De esta forma, tendrá menos información para buscar su problema.

mayoría de las personas (o al menos la mayoría de los ejemplos log4net) crean en realidad una instancia registrador estático por clase, el nombre de la clase (que no recuerdo la sintaxis exacta, pero es fácil encontrar ejemplos). Esto le proporciona un nivel muy alto de granularidad para controlar su registro.

En su archivo app.config, puede controlar todos los registradores en el mismo nivel configurando un solo registrador llamado "*" o puede configurar registradores específicos (usando el nombre de tipo completo) o incluso puede configurar por partes del nombre de tipo completamente calificado. Por ejemplo, se puede hacer muy fácilmente en todas las clases del espacio de nombres del registro ABC a nivel de "información", en todas las clases de registro DEF espacio de nombres en el nivel "error", y todas las clases de espacio de nombres de GHI no inician sesión en absoluto. Y todos estos registradores pueden iniciar sesión en el mismo destino (por ejemplo, archivo X).

podría haber sido demasiado tarde para ayudar, pero tal vez no ...

Answer 2

Supongo que podría tener el loggerName en su app.config.

¿Puedo preguntar por qué loggerName tiene que ser el mismo para toda la aplicación?

Answer 3

Seguimos un enfoque para usar log4net similar a esto.

Usamos log4net tanto en la aplicación principal como en los conjuntos de bibliotecas de clases. Escribimos una clase contenedora alrededor, para que todo el registro aparezca con el mismo tipo de configuración de donde lo llamemos y también para asegurarse de que sea un singleton. Esta clase contenedora se llama desde cualquier lugar dentro de nuestra aplicación.

Como resultado, las bibliotecas de clase y la aplicación principal cierran sesión en el mismo archivo de registro con la misma configuración, que es lo que queríamos. ¿Es esto lo que estabas tratando de lograr?

Answer 4

Primero, debe crear una clase contenedora (para desacoplar su aplicación del proveedor de registro).

Esta clase contenedora podría tomar el identificador del registrador. Si está utilizando un contenedor IoC, puede simplemente insertar el nombre del registrador o una instancia preconfigurada existente.

Si está utilizando la unidad (otros recipientes son similares), usted podría hacer algo como

// During application initialization 
IUnityContainer myContainer = new UnityContainer(); 
LoggingService concreteLoggingService = new LoggingService("logID"); 
myContainer.RegisterInstance<ILoggingService>(concreteLoggingService); 

// This would be injected, so you wouldn't see this, but it's here for consistency 
ILoggingService loggingService = myContainer.Resolve<ILoggingService>(); 
loggingService.LogMessage("message"); 

Ahora bien, esto supone que tiene un contenedor IoC.También puede crear un localizador de servicio:

// During application initialization 
ServiceLocator.Register<ILoggingService>(new LoggingService("logID")); 

// Retrieved as needed 
ILoggingService loggingServce = LoggingServiceLocator.Locate<ILoggingService>(); 
loggingService.LogMessage("message"); 

En el segundo caso, debe escribir todo el código de plomería. Con un contenedor IoC, lo obtienes de fábrica.

Answer 5

¿Qué hay de la implementación de su propia TraceListener para que sólo se puede utilizar Trace.Write a través de su aplicación?

Answer 6

nunca he visto a otro, patrón significativo, el uso de esto para log4net:

En la parte superior de cualquier clase que necesita registro, hacer:

private static ILog Log = LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType); 

En los AssemblyInfo.cs capas de acogida, hacer:

[assembly: log4net.Config.XmlConfigurator] 

En el inicio del host, realice la configuración programática de los appenders, etc., o use la configuración simple de app.config.

Fin de la historia. Sin envoltorios. Sin derivación de lo anterior.

Todas y cada otro patrón de uso que he encontrado, está hecho para eludir sin entender appenders log4net, incluyendo algunas/todas las respuestas aquí.