Return-Path: Delivered-To: apmail-jakarta-log4j-dev-archive@apache.org Received: (qmail 1105 invoked from network); 23 Oct 2002 08:10:42 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 23 Oct 2002 08:10:42 -0000 Received: (qmail 15071 invoked by uid 97); 23 Oct 2002 08:11:41 -0000 Delivered-To: qmlist-jakarta-archive-log4j-dev@jakarta.apache.org Received: (qmail 15047 invoked by uid 97); 23 Oct 2002 08:11:40 -0000 Mailing-List: contact log4j-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@jakarta.apache.org Received: (qmail 15035 invoked by uid 98); 23 Oct 2002 08:11:39 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-Id: <5.1.0.14.0.20021023093243.024b86e8@mail.qos.ch> X-Sender: ceki@mail.qos.ch X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 23 Oct 2002 10:10:33 +0200 To: "Log4J Developers List" From: Ceki =?iso-8859-1?Q?G=FClc=FC?= Subject: Re: cvs commit: jakarta-log4j/src/java/org/apache/log4j/xml Log4jEntityResolver.java DOMConfigurator.java In-Reply-To: <5.1.0.14.2.20021022185715.034f5860@shell.visi.com> References: <5.1.0.14.0.20021022205458.02f8eaa8@mail.qos.ch> <20021022174454.33918.qmail@icarus.apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 fix is just Paul Austin's Log4jEntityResolver patch: http://marc.theaimsgroup.com/?l=log4j-dev&m=103360153828273&w=2 See also: http://marc.theaimsgroup.com/?l=log4j-user&m=103236997401194&w=2 The locking problem was reported last year: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3058 I started off by following the fix description in report #3058. In other words, I copied clazz.getResourceAsStream("/org/apache/log4j/xml/log4j.dtd") to a ByteArrayInputStream and then handed the result to the InputSource() constructor. That is the code you tried yesterday. It turns out that Paul Austin's code, unmodified, also fixed the locking problem. His original code does not have an intermediary copy to ByteArrayInputStream. That is the code I checked in today. At 19:01 22.10.2002 -0500, you wrote: >That completely fixed the problem!!!! After doing a Tomcat manager >"remove" I was able to delete the log4j.jar where normally the OS would >have reported that file as being locked. This was on Win2k, if that makes >any difference. Can someone else verify this on Linux or other platforms? > >Thanks so much, Ceki! :-) > >I know I can look at the code, but it isn't obvious to me what the change >was the fixed this issue. Can you spell it out for future reference? > >Jake > >At 08:56 PM 10/22/2002 +0200, you wrote: > >>Could anyone check that the Log4jEntityResolver.java patch solves the >>log4j.jar locking problem? >> >>At 17:44 22.10.2002 +0000, ceki@apache.org wrote: >>>ceki 2002/10/22 10:44:54 >>> >>> Modified: src/java/org/apache/log4j/xml Tag: v1_2-branch >>> DOMConfigurator.java >>> Added: src/java/org/apache/log4j/xml Tag: v1_2-branch >>> Log4jEntityResolver.java >>> Log: >>> An apparently successful attempt at solving the log4j.jar locking >>> problem. >>> >>> Revision Changes Path >>> No revision >>> >>> >>> No revision >>> >>> >>> 1.49.2.3 +1 >>> -10 jakarta-log4j/src/java/org/apache/log4j/xml/DOMConfigurator.java >>> >>> Index: DOMConfigurator.java >>> =================================================================== >>> RCS file: >>> /home/cvs/jakarta-log4j/src/java/org/apache/log4j/xml/DOMConfigurator.java,v >>> retrieving revision 1.49.2.2 >>> retrieving revision 1.49.2.3 >>> diff -u -r1.49.2.2 -r1.49.2.3 >>> --- DOMConfigurator.java 9 Oct 2002 20:38:25 -0000 1.49.2.2 >>> +++ DOMConfigurator.java 22 Oct 2002 17:44:54 -0000 1.49.2.3 >>> @@ -659,16 +659,7 @@ >>> DocumentBuilder docBuilder = dbf.newDocumentBuilder(); >>> docBuilder.setErrorHandler(new SAXErrorHandler()); >>> >>> - Class clazz = this.getClass(); >>> - URL dtdURL = clazz.getResource("/org/apache/log4j/xml/log4j.dtd"); >>> - if(dtdURL == null) { >>> - LogLog.error("Could not find [log4j.dtd]. Used >>> ["+clazz.getClassLoader()+ >>> - "] class loader in the search."); >>> - } >>> - else { >>> - LogLog.debug("URL to log4j.dtd is [" + dtdURL.toString()+"]."); >>> - inputSource.setSystemId(dtdURL.toString()); >>> - } >>> + docBuilder.setEntityResolver(new Log4jEntityResolver()); >>> Document doc = docBuilder.parse(inputSource); >>> parse(doc.getDocumentElement()); >>> } catch (Exception e) { >>> >>> >>> >>> No revision >>> >>> >>> No revision >>> >>> >>> 1.1.2.1 +59 -0 >>> jakarta-log4j/src/java/org/apache/log4j/xml/Attic/Log4jEntityResolver.java >> >>-- >>Ceki >> >>TCP implementations will follow a general principle of robustness: be >>conservative in what you do, be liberal in what you accept from >>others. -- Jon Postel, RFC 793 >> >> >> >>-- >>To unsubscribe, e-mail: >>For additional commands, e-mail: -- Ceki TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. -- Jon Postel, RFC 793 -- To unsubscribe, e-mail: For additional commands, e-mail: