Bug 12366 - Cannot use Xerces 2.1.0 with XML configuration file because the file is not referred to as a URL by Log4J.
Cannot use Xerces 2.1.0 with XML configuration file because the file is not r...
Status: RESOLVED FIXED
Product: Log4j
Classification: Unclassified
Component: Configurator
1.2
PC All
: P3 major
: ---
Assigned To: log4j-dev
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2002-09-06 15:41 UTC by Derrick Koes
Modified: 2005-03-20 17:06 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Derrick Koes 2002-09-06 15:41:04 UTC
log4j:ERROR Could not parse input source [org.xml.sax.InputSource@cd107f].
java.net.MalformedURLException: no protocol: log4j.dtd
        at java.net.URL.<init>(URL.java:579)
        at java.net.URL.<init>(URL.java:476)
        at java.net.URL.<init>(URL.java:425)
        at org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.
java:807)
        at org.apache.xerces.impl.XMLEntityManager.startDTDEntity(XMLEntityManag
er.java:767)
        at org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScanner
Impl.java:275)
        at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(
XMLDocumentScannerImpl.java:841)
        at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XM
LDocumentFragmentScannerImpl.java:329)
        at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.jav
a:525)
        at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.jav
a:581)
        at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
        at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:253)
        at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.
java:201)
        at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java
:672)
        at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java
:616)
        at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java
:602)
        at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionCon
verter.java:460)
        at org.apache.log4j.LogManager.<clinit>(LogManager.java:145)
        at org.apache.log4j.Logger.getLogger(Logger.java:85)
        at org.apache.jsp.index$jsp._jspService(index$jsp.java:223)
        at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspSer
vlet.java:201)
        at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3
81)
        at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:247)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:243)
        at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)

        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:190)
        at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
torBase.java:531)
        at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
        at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve
.java:246)
        at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)

        at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:
2347)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:180)
        at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
        at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatche
rValve.java:170)
        at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:170)
        at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
468)
        at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)

        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:174)
        at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)

        at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:458
)
        at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551)
        at java.lang.Thread.run(Thread.java:536)
Comment 1 Derrick Koes 2002-09-06 17:34:21 UTC
I was not very careful with the stack trace.  If I would have looked more 
closely, I would have noticed the error is that "log4j.dtd" in the XML 
configuration file is not a valid URL.
Comment 2 Paul Austin 2002-09-12 18:09:42 UTC
I have also noted this problem and have looked at the code.

What the log4j code does is looks for the log4j.dtd file as a resource in the 
log4j.jar file and finds it. It then sets the system id on the input source for 
the log4j.xml file to be the url of the resource thus overiding the dtd from 
the document.

What happens in xerces2.1 is that it seems to ignore the system id dtd set in 
the input source and try to load the dtd using the dtd specified in the 
document. Therefore it tries to load the dtd using the log4j.dtd from the file 
system as a url which causes the error.

Should this be raised as a bug for xerces?

I would also like to see a fix for this.

Thanks,
Paul
Comment 3 Ceki Gulcu 2002-10-08 23:11:54 UTC
Which version of Tomcat were you using?
Comment 4 Andrew Everitt 2003-01-17 18:30:43 UTC
This is also a problem with Xerces 2.2.1.
It seems only to happen when the path has spaces in it for me. 

There is an alternative which does work with Xerces 2.2.1 which is to use an
Entity resolver.

When setting up the doc builder call:
docbuilder.setEntityResolver(new XMLEntityResolver(DOCTYPE_PUBLICID,
"/path/to/log4j.dtd"));

The XMLEntityResolver class looks like this:
public class XMLEntityResolver implements EntityResolver {
    
    String m_dtdId;
    String m_dtdResource;
    
    /**
     * Construct a new XMLEntityResolver
     * @param id the public Id that this entity resolver will match
     * @paramm resource the path to the resource to load the DTD from
     */
    public XMLEntityResolver(String id, String resource) {
        m_dtdId = id;
        m_dtdResource = resource;
    }
    
    public InputSource resolveEntity(String publicId, String systemId) throws
SAXException, IOException {
        if (publicId == null) {return null; }
        if ( publicId.equals(m_dtdId) ) {
            InputStream input = this.getClass().getResourceAsStream(m_dtdResource);
            InputSource isrc = new InputSource(input);
            return isrc;
        } else {
            return null;
        }
    }
    
}

HTH
Andi.
Comment 5 Jacob Kjome 2003-01-17 18:45:28 UTC
Check out the latest CVS for DOMConfigurator.  It *is* using an entity 
resolver.  I think Log4j-1.2.8 should be released because it both fixes a 
log4j.jar locking problem when Tomcat's ant manager tasks are used to 
install/remove a WAR structure.  With the stock 1.2.7, after Tomcat "remove", a 
clean will fail to delete the directory that was previously deployed because 
Tomcat will still old a lock on the log4j.jar in WEB-INF/lib.  With the recent 
changes, this is solved.  I'm not positive the changes solve this bug, but 
maybe you can try the latest CVS and test it out.  If it does solve it, I think 
that is pretty good reason to get out a 1.2.8 release ASAP.

Jake
Comment 6 Ceki Gulcu 2003-01-28 19:09:08 UTC
This has apparently caused Jboss folks trouble as well:

https://sourceforge.net/tracker/?
func=detail&atid=376685&aid=669112&group_id=22866
Comment 7 Eric Sachse 2003-02-14 18:51:44 UTC
I am getting this bug with Xerces 2.3.0 under IBM's Visual Age Java 3.5.  I am 
using Log4J 1.2.4

I am passing this in at the command line:  
-Dlog4j.configuration=file:/C:/myLogConfig.xml

log4j:ERROR Could not parse input source [org.xml.sax.InputSource@4ef3].
java.io.FileNotFoundException: /C:/Program%20Files/IBM/VisualAge%20for%
20Java/ide/project_resources/Jakarta%20Log4J/org/apache/log4j/xml/log4j.dtd
	java.lang.Throwable(java.lang.String)
	java.lang.Exception(java.lang.String)
	java.io.IOException(java.lang.String)
	java.io.FileNotFoundException(java.lang.String)
	java.net.URLConnection 
com.ibm.uvm.net.www.protocol.valoader.Handler.openConnection(java.net.URL)
	java.net.URLConnection java.net.URL.openConnection()
	java.io.InputStream java.net.URL.openStream()
	java.lang.String 
org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(java.lang.String, 
org.apache.xerces.xni.parser.XMLInputSource, boolean, boolean)
	void org.apache.xerces.impl.XMLEntityManager.startEntity
(java.lang.String, org.apache.xerces.xni.parser.XMLInputSource, boolean, 
boolean)
	void org.apache.xerces.impl.XMLEntityManager.startDTDEntity
(org.apache.xerces.xni.parser.XMLInputSource)
	void org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource
(org.apache.xerces.xni.parser.XMLInputSource)
	boolean 
org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(boolean)
	boolean 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(boolean)
	boolean org.apache.xerces.parsers.DTDConfiguration.parse(boolean)
	void org.apache.xerces.parsers.DTDConfiguration.parse
(org.apache.xerces.xni.parser.XMLInputSource)
	void org.apache.xerces.parsers.XMLParser.parse
(org.apache.xerces.xni.parser.XMLInputSource)
	void org.apache.xerces.parsers.DOMParser.parse(org.xml.sax.InputSource)
	org.w3c.dom.Document org.apache.xerces.jaxp.DocumentBuilderImpl.parse
(org.xml.sax.InputSource)
	void org.apache.log4j.xml.DOMConfigurator.doConfigure
(org.xml.sax.InputSource, org.apache.log4j.spi.LoggerRepository)
	void org.apache.log4j.xml.DOMConfigurator.doConfigure
(java.io.InputStream, org.apache.log4j.spi.LoggerRepository)
	void org.apache.log4j.xml.DOMConfigurator.doConfigure(java.net.URL, 
org.apache.log4j.spi.LoggerRepository)
	void org.apache.log4j.helpers.OptionConverter.selectAndConfigure
(java.net.URL, java.lang.String, org.apache.log4j.spi.LoggerRepository)
	org.apache.log4j.Logger org.apache.log4j.Logger.getLogger
(java.lang.String, org.apache.log4j.spi.LoggerFactory)
	org.apache.log4j.Logger org.apache.log4j.Logger.getLogger
(java.lang.String, org.apache.log4j.spi.LoggerFactory)
	org.apache.log4j.Logger net.hsn.clic.util.ClicCategory.getLogger
(java.lang.String)
	net.hsn.clic.util.ClicCategory net.hsn.clic.util.ClicCategory.getAppLog
(java.lang.String)
	net.hsn.clic.util.ClicCategory net.hsn.clic.util.ClicCategory.getAppLog
(java.lang.Class)

Comment 8 Jacob Kjome 2003-02-14 20:00:52 UTC
Hi Eric,

Try using the log4j jar file I am linking to below.  It is log4j-1.2.7 + the 
modified entity resolver stuff I mentioned in my previous comment.  If that 
fixes the problem, I really think we should release log4j-1.2.8 soon.

http://barracudamvc.org/cvs/Barracuda/WEB-INF/lib-cvs/log4j-1.2.7a.jar

Jake
Comment 9 Eric Sachse 2003-02-14 20:39:48 UTC
Jake

The 1.2.7a jar file worked with my unit tests.  I want to run some extensive 
regression tests before I release this to my other developers and ultimately to 
my production system, but this looks like a resolution for my issues.

I cannot wait for the 1.2.8 release.

Thanks
Comment 10 Jacob Kjome 2003-02-14 22:00:15 UTC
Very cool!

Ceki, is it possible to release log4j-1.2.8 sometime soon?  Once it is 
released, this bug can be resolved as fixed.

Jake
Comment 11 Ceki Gulcu 2003-02-15 14:21:10 UTC
As much as I would like to stop making 1.2 based releases, it might well be 
necessary. I'll look into this on monday.
Comment 12 Ceki Gulcu 2003-02-18 17:43:39 UTC
Fixed in 1.2.8.