Re: Log4jXMLCLogger class
Jacob Kjome <[email protected]>
| Newsgroups | gmane.comp.java.enhydra.xmlc |
|---|---|
| Message-ID | <[email protected]> |
Very nice. Looks very much like the Log4jAvalonLogger Log4j wrapper now which is a good thing. I've got a couple comments... Richard Kunze mention another level of logging that is, apparently, almost exclusively used by LazyDOM. Here is what he said... > >If you want, you can also include "STATS" in the value, but this mainly > > gives exhaustive statistics about DOM parsing, caching and node > > expansions in LazyDOM. I'm really not sure if this would affect the Log4jXMLCLogger, though. I guess maybe you can make that determination. See the following sources.... org/enhydra/xml/dom/DOMStats.java org/enhydra/xml/xmlc/servlet/XMLCContext.java org/enhydra/xml/xmlc/servlet/XMLCContextInit.java Other than that, you might want to add more Log4j-like methods such as... public final boolean isInfoEnabled() public final void info(final String message) public final void info(final String message, final Throwable throwable) and so on.... These more Log4j-like methods could simply call the existing XMLCLogger-like methods that already exist. Note that in Log4j, the Category class only contains isDebugEnabled() and isInfoEnabled(). Other levels don't contain boolean "enabled" methods in Log4j. That would make it easier for coders to switch either directly to Log4j or to another wrapper class without having to change much code since they wouldn't have to use the XMLCLogger specific methods. Of course it would be up to the coder to decide what they want to use, but at least they have the choice. Anway, if you feel these suggestions are unnecessary, then let me know. What you have posted is acceptable so if you don't feel like making the changes I suggested, this will definitely do. Jake At 03:42 PM 7/15/2003 +0200, you wrote: >Hi Jacob! > >As you suggested, we renamed our Log4j wrapper class to Log4jXMLCLogger.java. > >Also, we think that the second class Log4jXMLCAdapter.java is not >necessary for us. > >If this class is OK for XMLC, please include this class into XMLC final. > > > >Greetings, > > > >Sinisa Milosevic > >Together, Serbia