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, [EMAIL PROTECTED] 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:   <mailto:log4j-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@;jakarta.apache.org>
--
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:   <mailto:log4j-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@;jakarta.apache.org>

Reply via email to