DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42623>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42623


[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO




------- Additional Comments From [EMAIL PROTECTED]  2007-06-08 18:00 -------
Quite a few things seem a little odd.  First, I'll acknowledge that the use of 
namespaces in the log4j 
configuration is atypical, but that predates my involvement with log4j.  At 
this point in the lifecycle of 
log4j 1.2, changing the configuration file format is not an option.

You mention than an exception is thrown.  Any non-fatal errors detected by the 
XML parser on a call to 
DOMConfigure.configure() should result in a message to the console but would 
not stop processing 
(see org.apache.log4j.xml.SAXErrorHandler and the catch block in 
o.a.l.xml.DOMConfigurator.doConfigure(ParseAction...).  If the parser was 
either correctly or incorrectly 
identifying a validation error, log4j should ignore it and continues processing.

Your sample output suggests that it is coming from some code other than log4j 
reading a log4j 
configuration file.  I see no place in the log4j code where 
"ConfigurationInXml" appears.

There are several XML parsers that could be used and they can slightly vary in 
their interpretation of the 
XML recommendations, particularly in atypical cases.  If you could identify the 
parser in use that would 
be very helpful if it is a parser bug.  The value returned by 
DocumentBuilderFactory.newInstance
().getClass().toString() would probably be enough to at least identify the 
parser family.

To take this further, I think we need to see an sample app including your 
configuration file, a 
description of your expected and actual behavior, and the JVM (vendor, version 
and platform).  Please 
be clear whether the log4j method is raising an exception to the caller or if 
an exception is raised and 
caught within log4j.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to