Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 63404 invoked from network); 6 Jun 2002 18:08:24 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 6 Jun 2002 18:08:24 -0000 Received: (qmail 6767 invoked by uid 97); 6 Jun 2002 18:08:21 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 6734 invoked by uid 97); 6 Jun 2002 18:08:20 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 6716 invoked by uid 98); 6 Jun 2002 18:08:19 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: costinm.sfo.covalent.net: costin owned process doing -bs Date: Thu, 6 Jun 2002 11:08:10 -0700 (PDT) From: costinm@covalent.net X-X-Sender: costin@costinm.sfo.covalent.net To: Jakarta Commons Developers List cc: List Tomcat-Dev Subject: Logging: more classloader problems. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N The problem: it won't work if commons-logging.jar is installed in the parent class loader, and log4j.jar ( or another logger ) is installed in a child loader ( like WEB-INF/lib ). What happens: - the factory uses the thread class loader to check if the log4j ( or any other impl. ) exists ( and it does ). - it creates an instance of the Logger adapter. This will be created using parent loader ( the one that loads commons-logging ). - the Logger instance makes references to Category or other classes that are used in it's implementation. End of story, since the class loader can't find the reference. This works fine for JAXP because the adapter for a parser is part of the parser jar. It doesn't work for c-l because the adapter is in the root loader ( with the API), not with the logging impl. That doesn't affect people who just use a single logger or can put the logger impl. in the same place with common-logging. It only affect containers like tomcat, when you want to let each webapp use it's own logger impl. of choice. I tried all kind of introspection games, it won't work. The only solution I see is to make sure the adapters are in the same place with the logger. Solution: Split commons-logging.jar in commons-logging-api.jar ( only the API and the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. Alternatively, leave commons-logging.jar as it is and create a second commons-logging-api.jar. The -api will be included in the common loader. Each webapp will have to include commons-logging.jar ( or -impl ), and it's own logger. Or course, the best would be to have the adapter included in the logger impl. What do you think ? Craig, Remy can we make another c-l dot release with this change ? ( I'll do some more testing to see how it works ) Costin -- To unsubscribe, e-mail: For additional commands, e-mail: