On Dec 2, 2004, at 4:09 AM, Ceki G�lc� wrote:
At 10:23 PM 12/1/2004, Curt Arnold wrote:
I've updated the bug report with a shot at replaying location information.
Thank you.
The JoranConfigurator normalizes everything so all JoranInterpreter sees is local names ("configuration", "logger") etc in the "http://jakarta.apache.org/log4j/"; namespace.
Hmm, we should use the "http://logging.apache.org/log4j/"; namespace or maybe just "http://logging.apache.org/";.
JoranInterpreter currently ignores the namespaceURI passed to it by JoranConfigurator. I just used the existing namespaceURI to give it a value.
The old namespace needs to be recognized by JoranConfigurator to remain compatible with existing configuration files. However, it could also recognize an additional namespace that doesn't conceptually tie the document to Jakarta. However adding that new namespace would compel log4cxx and log4net to support it also so they could still trade configuration files. I wouldn't establish a new namespace until we've had a chance to review any differences between the implementations and then more explicitly define the namespace with a schema or similar.
I think doConfigure should return a boolean to relay whether the configuration was successful. You couldn't rely on getErrorList.size() > 0 to indicate failure since a warning would go in the error list, but would not cause doConfigure to fail.
Good point. However, keep in mind that none of the joran actions will add a warning to the error list. Only serious errors are added there. So we are left with the parser. From the top of your head, do you have an example of a warning reported by the parser which would be less serious than an error? If you look at the checkIfWellformed method, you'll notice any fatalError, error or warning reported by the parser will cause joran to skip configuration. In short, the current wellformedness checks do not differentiate between fatalError, error and warning messages reported by the parser.
Warnings are fairly unusual and can (and in this case) should be ignored. For example, Xerces-J can be configured to emit a warning if an attribute is defined twice. The XML spec is clear which definition takes precedence.
<!DOCTYPE foo [ <!ELEMENT foo EMPTY> <!ATTLIST foo value CDATA #IMPLIED> <!ATTLIST foo value CDATA #IMPLIED> ]> <foo value="5"/>
I think you might also get warnings if non-normalized characters appear in the source (something like c + ~ instead of the equivalent combined character).
Errors are typically generated during validation. They aren't like well-formedness errors that the XML spec requires processors to abandon processing, but they do indicate that things aren't perfect. Since we aren't validating, the only things I could find in Xerces-J that would generate plain errors are duplicate element definitions and entity definitions.
I would recommend that only fatal errors stop configuration (which I think is the current state of my last submission). Any fatal errors encountered during a parse will result in the parse method throwing an exception, errors and warnings will not unless they are escalated by a handler. Unless you were trying to generate them, I would not think we would ever see an error or warning and there is no ambiguity in the proper representation.
If you want atomicity within JoranInterpreter, then you probably need to replay the parse events twice. One pass to check that the actions do not raise an exception and once to actually do the action. Since we are using SAX interfaces, I would keep with their error conventions. If an action wants to stop processing, it should report a fatal error and throw an SAXException.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
