Curt,
While toying with XML namespaces and in particular with setNamespaceAware() set to true, I came across the following variant which is unfortunately illegal because the "log4j" prefix is not bound to anything.
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE log4j:configuration>
<log4j:configuration xmlns='http://logging.apache.org'> <logger>...</logger> ... </log4j:configuration>
In namespace aware mode, Crimson ingurgitates it happily whereas Xerces barfs on it. In namespace aware mode turned off, the above form goes through without hindrance. It's not a legal form so I won't waste more time discussing it.
I'd like to note that your changes constitute real progress compared to what we had previously. No complaints here. :-)
At 05:34 PM 12/1/2004, Curt Arnold wrote: [cut]
There are a couple other things I'd like to fix while I'm at it and which should not add much complexity with the approach that I'm thinking about.
First, log4j's depends on the log4j namespace prefix. From an XML Infoset view, the following documents are identical, but log4j will only correctly interpret the first:
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/";> <root/> </log4j:configuration>
<log4cxx:configuration xmlns:log4cxx="http://jakarta.apache.org/log4j/";> <root/> </log4cxx:configuration>
<configuration xmlns="http://jakarta.apache.org/log4j/";> <root xmlns=""/> </configuration>
An XML editor would be well within its rights to switch between the forms which may result in a InfoSet identical but unusable configuration file.
Second, log4j has the legal but unusual structure of a namespace qualified document element <log4j:configuration> with non-namespaced child elements. I'd like to allow log4j to accept either non-namespaced or log4j namespace qualified child elements. So log4j could take the following two documents which are not Infoset equivalent to the previous documents, but would be interpreted identically.
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/";> <log4j:root/> </log4j:configuration>
<configuration xmlns="http://jakarta.apache.org/log4j/";> <root/> </configuration>
Third, have log4j ignore elements that are namespace qualified, but are not in a log4j recognized namespace. This would allow existing Resource Description Format metadata to appear in configuration files:
<configuration xmlns="http://jakarta.apache.org/log4j/";>
<rdf:Description xmlns:rdf="http://www.w3.org/..."; xmlns:dc="http://...";>
<dc:creator>Ceki Gulku</dc:creator>
<dc:title>The most beautiful logging configuration file in the world</dc:title>
</rdf:Descripton>
<root/>
</configuration>
The approach that I'm thinking of is to parse the configuration once, collect objects that correspond to the startElement and endElement events but with some minor namespace normalization and dropping foreign elements, then replay those normalized events to JoranInterpreter. It should not be necessary to make any changes to JoranInterpreter.
That's quite excellent.
-- Ceki G�lc�
The complete log4j manual: http://qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
