logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gulcu <...@urbanet.ch>
Subject Re: XML parsing problem..
Date Sat, 23 Dec 2000 10:02:48 GMT

Hello,

This problem is corrected in log4j 1.0 such that the DOMConfigurator will 
require only DOM Level 1 instead of DOM Level 2.

If you can't wait until 1.0 is released, then try the hack suggested by 
Endre Stølsvik <Endre@Stolsvik.com> which works very well:

/**
    Used internally to parse appenders by IDREF.
*/
protected
Appender findAppenderByReference(Element appenderRef) {
   String appenderName = appenderRef.getAttribute(REF_ATTR);
   Appender appender = (Appender) appenderBag.get(appenderName);
   if(appender != null) {
     return appender;
   } else {
     Document doc = appenderRef.getOwnerDocument();


     // DOESN'T WORK!! :
     // Element element = doc.getElementById(appenderName);

     // Endre's hack:
     Element element = null;
     NodeList list = doc.getElementsByTagName("appender");
     for (int t=0; t<list.getLength(); t++) {
       Node node = list.item(t);
       NamedNodeMap map= node.getAttributes();
       Node attrNode = map.getNamedItem("name");
       if (appenderName.equals(attrNode.getNodeValue())) {
         element = (Element) node;
         break;
       }
     }
     // Hack finished.

     if(element == null) {
       LogLog.error("No appender named ["+appenderName+"] could be found.");
       return null;
     } else {
       appender = parseAppender(element);
       appenderBag.put(appenderName, appender);
       return appender;
     }
   }
}

This fixes the jaxp parser problem.

Chris' explanation is right on target. Endre's solution, that is 
replacing  getElementById with an equivalent for loop, is exactly the right 
approach. I must have been very confused when switching to the DOM level 2 
API. :-)

Hope this helps, Ceki




At 00:35 23.12.2000 -0800, Christopher Taylor wrote:
>On 12/17/00 3:39 AM, "Endre Stølsvik" <Endre@Stolsvik.com> wrote:
>
> > I'm trying to get the XML config thing to work with the jaxp early access
>Jaxp 1.1 isn't ready yet.  I think Ceki mentioned that earlier in the
>mailing list, but I could be mistaken.
>
>For now, we're stuck with single-sourcing the XML parser (Xerces... At a
>700K footprint), although DOMConfigurator could be rewritten to use a hollow
>replacement approach:
>
>- For every ID encountered in the config file, add the constructed component
>into a hashtable using the value of the ID attribute as the key
>- For every IDREF encountered in the config file, lookup the associated
>object from the hashtable.  If that association has not been made (the ID'd
>component comes later in the document), defer the construction of the
>component until later (add it to a stack?)
>- Once the file has been completely traversed, revisit the deferred
>components
>
>This solution is convoluted and error-prone, which is why (IMHO) Ceki chose
>to require DOM level 2 so he could safely search the document after each
>encountered IDREF.
>
>The only limitation to the new system that I am aware of is if you're
>residing within an application server (such as Jakarta's Tomcat) and you try
>and use DOM level 2 interface bindings.  Since Tomcat uses JAXP (AFAIK) for
>loading the server's configuration file information, only the DOM level 1
>bindings are loaded (and anything using Log4j's DOMConfigurator will crash).
>The solution is replacing the parser.jar from Sun with the xerces.jar from
>xml.apache.org in your Tomcat lib directory.
>
>-Chris
>
> > 1.1 from SUN. This is my classpath, where the three last ones is the jaxp
> > thingy :
> >
> > .:/usr/java/jdk1.3/jre/lib/rt.jar
> > /usr/java/jsdk2.2/servlet.jar
> > /usr/java/third/webmacro/webmacro.jar
> > /usr/java/jaxp-1.1ea/crimson.jar
> > /usr/java/jaxp-1.1ea/jaxp.jar
> > /usr/java/jaxp-1.1ea/xalan.jar
> >
> > ------------
> > I then try to run a class called Test. It's an adaption of the xerces
> > based XMLSample to jaxp1.1, and uses one of the config files there. Check
> > the log4j log entries at the bottom of the run here:
> >
> > endre@endresin:~/testlog/classes$ java Test testconf1.xml
> > "doc.getDocumentElement()" gives:
> >
> > <configuration configDebug="null" disableOverride="null">
> >
> >       <appender name="A1" class="org.log4j.FileAppender">
> >           <param name="File" value="A1.log" />
> >           <param name="Append" value="false" />
> >           <layout class="org.log4j.PatternLayout">
> >               <param name="ConversionPattern" value="%t %-5p %c{2} - 
> %m\n" />
> >           </layout>
> >       </appender>
> >
> >       <appender name="STDOUT" class="org.log4j.FileAppender">
> >               <param name="File" value="System.out" />
> >
> >               <layout class="org.log4j.PatternLayout">
> >                  <param name="ConversionPattern" value="%d %-5p [%t] %C{2}
> > (%F:%L) - %m\n" />
> >               </layout>
> >       </appender>
> >
> >       <category name="Test" additivity="true">
> >         <priority value="debug" />
> >         <appender-ref ref="A1" />
> >       </category>
> >
> >       <root>
> >          <priority value="debug" />
> >          <appender-ref ref="STDOUT" />
> >       </root>
> >
> > </configuration>
> >
> > log4j: No appender named [A1] could be found.
> > log4j: No appender named [STDOUT] could be found.
> > log4j: No appenders could be found for category (Test).
> > log4j: Please initialize the log4j system properly.
> >
> > ------------------
> >
> > What's happening is apparently that these lines in DOMConfigurator.java
> > mess up (it does parse the root and categories "correctly", but when it
> > needs the appenders, it fails):
> >
> > ...
> > Document doc = appenderRef.getOwnerDocument();
> > Element element = doc.getElementById(appenderName);
> > if(element == null) {
> >   LogLog.error("No appender named ["+appenderName+"] could be found.");
> >   return null;
> > } else {
> > ...
> >
> > So, the getElementById isn't giving anything back. Why is this? I guess it
> > have something to do with me using jaxp1.1 and this being made for xerces,
> > but then there is something wrong somewhere, right?
> >
> > Anybody had any experience with this?
> >
> > Thanks!
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org


Mime
View raw message