If log4j.dtd can't be found by getResourceAsStream() (likely running in an IDE as described on log4j-dev on 2007-08-23 by Scott Deboy), Log4JEntityResolver would return null which would result in the parser attempting to locate the resource using the URL. The change causes Log4JEntityResolver to return an InputSource backed by an empty ByteArrayInputStream which will prevent the parser from trying to locate log4j.dtd on its own.
Just tried the xml-based appender/receivers in Chainsaw in an IDE without log4j src/main/resources in my classpath - I still get an error: 'log4j:ERROR Could not find [log4j.dtd]. Used [sun.misc.Launcher$AppClassLoad@...] class loader in the search.
That would be as expected, LogLog.error is still called if the resource could not be found. The thing that changed was instead of returning null which tells the parser to try to find it on its own, an empty InputSource is returned which will prevent the parser to try to find it on its own. So hopefully you lost the exception from the parser when it could not find log4j.dtd. Could downgrade it from a LogLog.error to a LogLog.warn. There are two issues here: one is what do in the case that the resource can not be found. Other than potentially downgrading the message to a LogLog.warn, I think the fix is good. The other is why you can't find the resource and there isn't enough to go on for me to figure that out and to decide if it is a log4j issue or a IDE project issue.
Changes committed rev 569053 and 569147 and released in log4j 1.2.15.