Comment connecter le bloc statique pour une bibliothèque jar

Question

j'ai la situation suivante:

• Nous avons une bibliothèque commune (faite par notre organisation) qui ont une certaine classe qui est statique (parce que pour l'optimisation ont beaucoup enregistrements en mémoire) et il est déployé dans le répertoire lib du tomcat (pour accéder à toutes les applications Web déployées).
• La classe statique besoin d'accéder à DB conection, et pour cela (en cas de problème), nous utilisons log4j, mais aproche générons le problème suivant:

log4j: WARN Aucun appenders se trouve pour logger (dev.sample.test.TestLog4J). log4j: WARN Veuillez initialiser correctement le système log4j.

And also when the server is stop, there are some memory leaks in the webapps that load (or use) the static class: 
Jul 24, 2014 11:29:34 AM org.apache.catalina.core.StandardContext reload 
INFO: Reloading Context with name [/fake_smsc] has started 
Jul 24, 2014 11:29:34 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads 
SEVERE: The web application [/fake_smsc] appears to have started a thread named [MultiThreadedHttpConnectionManager cleanup] but has failed to stop it. This is very likely to create a memory leak. 
Jul 24, 2014 11:29:34 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads 
SEVERE: The web application [/fake_smsc] appears to have started a thread named [Timer-2] but has failed to stop it. This is very likely to create a memory leak. 
Jul 24, 2014 11:29:34 AM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks 
SEVERE: The web application [/fake_smsc] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@65686a12]) and a value of type [org.mockito.configuration.DefaultMockitoConfiguration] (value [org.mockito.configuration.DefaultMockitoConfiguration@2a0bf7c1]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. 
Jul 24, 2014 11:29:34 AM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks 
SEVERE: The web application [/fake_smsc] created a ThreadLocal with key of type [com.google.gson.Gson$1] (value [com.google.gson.Gson$1@7c43d507]) and a value of type [java.util.HashMap] (value [{}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. 
Jul 24, 2014 11:29:34 AM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks 
SEVERE: The web application [/fake_smsc] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@4956fe4d]) and a value of type [org.mockito.internal.progress.MockingProgressImpl] (value [iOngoingStubbing: org.mockito.internal.stubbing.OngoingStubbingImpl@6e5196d8, verificationMode: null, stubbingInProgress: null]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. 
Jul 24, 2014 11:29:35 AM org.apache.catalina.core.StandardContext reload 
INFO: Reloading Context with name [/fake_smsc] is completed 
Jul 24, 2014 11:29:43 AM org.apache.catalina.core.StandardServer await 
INFO: A valid shutdown command was received via the shutdown port. Stopping the Server instance. 
Jul 24, 2014 11:29:43 AM org.apache.coyote.AbstractProtocol pause 
INFO: Pausing ProtocolHandler ["http-bio-9191"] 
Jul 24, 2014 11:29:43 AM org.apache.coyote.AbstractProtocol pause 
INFO: Pausing ProtocolHandler ["ajp-bio-9109"] 
Jul 24, 2014 11:29:43 AM org.apache.catalina.core.StandardService stopInternal 
INFO: Stopping service Catalina 
Jul 24, 2014 11:29:44 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads 
SEVERE: The web application [/sms_services] appears to have started a thread named [MultiThreadedHttpConnectionManager cleanup] but has failed to stop it. This is very likely to create a memory leak. 
Jul 24, 2014 11:29:44 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads 
SEVERE: The web application [/sms_services] appears to have started a thread named [ActiveMQ Connection Executor: vm://localhost#2] but has failed to stop it. This is very likely to create a memory leak. 
Jul 24, 2014 11:29:44 AM org.apache.coyote.AbstractProtocol stop 
INFO: Stopping ProtocolHandler ["http-bio-9191"] 
Jul 24, 2014 11:29:44 AM org.apache.coyote.AbstractProtocol stop 
INFO: Stopping ProtocolHandler ["ajp-bio-9109"] 
Jul 24, 2014 11:29:44 AM org.apache.coyote.AbstractProtocol destroy 
INFO: Destroying ProtocolHandler ["http-bio-9191"] 
Jul 24, 2014 11:29:44 AM org.apache.coyote.AbstractProtocol destroy 
INFO: Destroying ProtocolHandler ["ajp-bio-9109"] 

ce problème, il est bien documenté à: https://wiki.apache.org/commons/Logging/StaticLog mais ne pas une solution propre à ce problème (comme une configuration dans le fichier logging.properties du serveur tomcat)

Le code de la classe java qui se connecte est très simple:

public class TestLog4J { 
    private static Logger log = Logger.getLogger(TestLog4J.class); 

    static { 
     log.debug("We created the instance of the Test class."); 

     try { 
      //Do black magic connecting to the db 
      connectDatabase(); 
     } catch (Exception e) { 
      log.error("What a Terrible Failure (WTF): ", e); 
     } 
    } 
} 

Alors, quels sont les choix? Il semble un peu moche faire la "connexion" avec System.out.println (...), donc j'espère que peut-être quelques travaux autour de ce problème en utilisant log4j.

Cordialement, et thx pour Souhaite réponses :)

Answer 1

Ok, la solution de son dans le lien que je posté:

import org.apache.commons.logging.Log; 
    import org.apache.commons.logging.LogFactory; 

    public static void doStuff(...) { 
    Log log = LogFactory.getLog("stuff"); 
    log.warn(...); 
    } 

https://wiki.apache.org/commons/Logging/StaticLog

Les références dans le journal de l'enregistreur statique privé = Logger.getLogger (TestLog4J.class); doit être supprimé, et tous les appels aux logs dans les méthodes statiques, block et class doivent être donde avec la méthode getLog de LogFactory, aussi le journal commons-logging - * .jar doit être dans le dossier lib du serveur tomcat, donc le custom lib peut le localiser (et aussi le log4j.jar bien sûr).