On Dec 2, 2004, at 9:33 AM, Curt Arnold wrote:
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.
I was rambling there and will ramble some more. I think it is reasonable to have an non-wellformed XML configuration result in no change to the hierarchy. However, I'm not sure if it is desirable (it definitely adds complexity) that an failure in an action would cause the entire configuration to be rolled back.
It would be good to provide some feedback to the caller on the effectiveness of the doConfigure. I assume that we weren't throwing any exceptions from doConfigure() to maintain the programming model from the previous DOMConfigurator.configure() method.
I see multiple exit conditions and no way to determine which one occurred.
1. IOException on parse action, hierarchy unchanged. Example: file not found.
2. SAXException on parse action, hierarchy unchanged. Example, non-wellformed document.
3. Error during playback, previous and subsequent actions are effective. Example: unrecognized appender class name, unrecognized level, unrecognized reference.
4. Fatal error during playback: previous actions are effective. Examples: Unknown.
5. No errors, hierarchy modified.
What looks like the cleanest way to give the caller some insight into the exit condition is to change the doConfigure's to:
boolean configure(final Whatever fileURLetc, final LoggerRepository repo, final List errorList)
throws IOException, SAXException {
}
let any IOException or SAXException from the parser.parse() call percolate out to the caller (which will occur before any modifications to the hierarchy). Return false if any Action posted a error, true if there were no errors, but possibly warnings. Adding the error list as an argument, allowing null, should allow JoranConfigurator to be stateless if getLogger is reworked. Ideally, actions should not be allowed to throw a SAXException which would eliminate exit condition 4 since there would not be a clean way to distinguish condition 2 and 4.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
