I think that I have the DOMConfigurator's back in the build. You may need to temporarily create an empty file at include/libxml/tree.h to get the Windows build to compile.

There were a couple of test cases that I needed to hack. tests/src/xml/domtestcase::test1 would produce a temp.a1 file that did not have duplicate entries for each logging event (once for the event at a high level logger and once at the root). tests/src/varia/errorhandlertestcase.cpp seem pretty broken (it never actually made a log request, but expected stuff in the log file). According to Ceki in a totally unrelated discussion, the corresponding test in log4j is dead. I've commented it out for the moment, but will likely delete it.

With the changes, you must have libxml2 installed to create the Unix build.



On Jan 11, 2005, at 6:04 PM, Curt Arnold wrote:

Been a busy day. It would have been good if I had at least known what parts of log4cxx were regressed from 0.9.7 before I got everybody excited. Hopefully I can catch up a bit tonight.

It looks like DOMConfigurator is currently disabled. The long-term goal is to migrate to the log4j Joran configurator (which is replacing log4j's DOMConfigurator) and APR's bundled Expat parser. However, I don't think that will happen fast enough for 0.9.8. I'll take a look at seeing if I can get the existing implementations back in the build.

I'll report back to the list after I had a chance to investigate.


On Jan 11, 2005, at 5:40 PM, Drapal, Myron E (Myron) wrote:

I am not able to build my existing code (based on 0.9.7) with the latest
CVS code, and it seems that it has to do with the (partial) disablement
of DOMConfigurator (which I use). Looking at the code a bit, it looks
like the log4cxx/portability.h header file is supposed to define
LOG4CXX_HAVE_XML, LOG4CXX_HAVE_LIBXML2 and/or LOG4CXX_HAVE_MS_XML (Is
this a correct assessment?). If so, what is the intent of each of these
defines, and what should their default settings be for Windows (and
non-Windows) environments? If I set them "correctly", will the
DOMConfigurator work as it did before?


Myron Drapal
[EMAIL PROTECTED]


<Drapal, Myron E (Myron).vcf>




Reply via email to