Hello Curt,
You should also look at DOMConfigurator, particularly lines 758 to 768 (CVS HEAD). Here are those lines:
DocumentBuilder docBuilder = dbf.newDocumentBuilder();
docBuilder.setErrorHandler(new SAXErrorHandler());
docBuilder.setEntityResolver(new Log4jEntityResolver()); // we change the system ID to a valid URI so that Crimson won't
// complain. Indeed, "log4j.dtd" alone is not a valid URI which
// causes Crimson to barf. The Log4jEntityResolver only cares
// about the "log4j.dtd" ending.
inputSource.setSystemId("dummy://log4j.dtd");Document doc = docBuilder.parse(inputSource);
That is how we have resolved "log4j.dtd" in the past.
At 07:57 AM 12/1/2004, Curt Arnold wrote:
I've been able to take a look at the current CVS version of JoranConfigurator. It does appear than it is unnecessarily discarding the base URLthat would be needed to resolve relative URI's in the document. If doConfigure(URL) and doConfigure(String) called doConfigure(InputSource) instead of calling doConfigure(InputStream), the base URL would be preserved and relative URL's could be resolved.
Really? I would have never thought of that.
There are a couple of other troubling things about the code.:
Substantial duplication between doConfigure(URL) and doConfigure(String)
Yes, but I think necessary duplication. You need to be able to collect errors specific to doConfigure(URL) or doConfigure(String), hence the duplication. If you can think of something better, I'm all ears.
Substantial duplication in o.a.l.joran.util.checkIfWellFormed(URL) and checkIfWellformed(String)
Again, necessary duplication.
The configuration file is parsed twice, once in checkIfWellFormed and once in doConfigure. Each time reading the configuration from disk (or net or however the URL is resolved).
I assume that the two-pass approach is designed to make configuration atomic, so that any error in the configuration file results in no configuration being applied.
Exactly.
You could copy the InputStream into a byte array and use MemoryInputStream to prevent the file from being access twice, but I think it be better to only parse once.
It would be nicer to parse only once but how to do you guarantee well-formedness with only a single pass?
Double file access is the consequence of double parsing. Eliminating the latter implies eliminating the former.
One approach would be to try to stack configuration actions in a list, but I think that would be pretty complicated. It appears that the Joran configurator ignores any character content (other than within attribute). It should be fairly simple to parse the document and create a list of start and end element events, then replay the events into the Joran configurator.
You could do that but why bother?
Eliminating the duel fetching of the configuration file would probably come close to paying for the expense of validating the configuration file against a log4j.dtd embedded as a resource.
I don't think you can declare all valid config files with a DTD. For one, Joran can configure sub-components
of log4j components, or sub-components of sub-components all which were unknown at compile time. Joran can also be taught new parsing rules on the fly, rules which were unknown to the dtd. Maybe a very loose DTD would cut it. However, how would a DTD help with the double parse problem? Can you explain?
JoranConfiguration as far as I can tell wouldn't currently complain about elements containing character content.
??
Implicit is misspelled in "addImplcitAction", getapplicableActionList on org.apache.joran.Interpreter.
Thanks.
I'd be willing to take a shot if you'd like.
Sure, please do.
-- Ceki G�lc�
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
