Thanks for the help Nicko, I'm actually writing a .NET service that will run 24x7 with (hopefully) no restarts :)
So I think the solution you have proposed would work in this instance of the problem. At other times, however, we would use log4net from an application and in those cases we would have to think of something else. Just to be clear, log4net is ready, without modifications to handle the solution you have described below? Cheers Matthew James Easlea -----Original Message----- From: Nicko Cadell [mailto:[EMAIL PROTECTED] Sent: Wednesday, 9 June 2004 8:40 AM To: 'Log4NET User' Subject: RE: XML Layout Another solution is to ignore the main issue. A log file using XML format is not appendable. By this I mean that opening an existing file and appending breaks the file format. Therefore we would just say that using the FileAppender in append mode with this file format is not supported. The header is written when the file is opened, the footer when the file is closed. The file cannot be opened and added to. This may not be the most useful position, however in conjunction with a rolling strategy it may work. If you can setup a rolling strategy that rolls the file on startup if it exists then you have a situation where you never need append to the file. Each time the app starts it rolls the current log file out of the way before creating a new file. This will impact the rolling strategies you may be able to select for this file format. You may also end up with a lot of files just containing the header and footer (one per execution) if you aren't logging any messages. Nicko > -----Original Message----- > From: Ceki G�lc� [mailto:[EMAIL PROTECTED] > Sent: 08 June 2004 10:52 > To: Log4NET User > Cc: [email protected] > Subject: RE: XML Layout > > > Hi Nicko, > > We are facing exactly the same problem in log4j. As you > describe, a file handled by a RollingFileAppender may open > and close a file multiple times, writing the header and > footer as many times. > > > If one ignores good software design principles for a moment, > in particular separation of concerns, the rolling appender > could check if the size of the file being opened was larger > then the length of the header and if so, assume that the > header was already added, and skip writing the header. That > would ensure that headers are written at most once with a > high degree of assurance. I can't imagine a scenario were the > header would not be written. (However, I have observed that > under Windows Java does not always report file sizes > accurately which might render the whole file size counting > approach useless at best.) > > The footer case is even more complicated. The gist of my > current best solution is to write the footer when the file is > rolled over. When the file is closed due to for example the > application closing, the footer would *not* be written. This > approach suffers from problems associated with high > complexity solutions and requires changes in super-classes > such as WriterAppender. Unfortunately, it is the only > solution I can think of that might work. > > For the time being in log4j v1.3 land, we are pretending the > header/footer problem does not exist in exchange for a simple > and robust code that works (except for the incorrect > header/footer count). > > Do you have any ideas about solving this? > > (I am CCing [email protected] for the record but the > discussion should continue here at [EMAIL PROTECTED]) > > > At 11:15 AM 6/8/2004, Nicko Cadell wrote: > >Matthew, > > > >Layouts support Header and Footer properties. These are written each > >time the file is opened or closed respectively. The issue is that a > >file may be opened and closed multiple times, therefore there may be > >multiple headers and footers in the file. To work as an XML > file there > >must only be one pair of headers and footers and they must > exist at all > >times. When a file is reopened for writing (e.g. when the app is > >restarted) the footer would have to be stripped off before > writing the > >next events. This does not sit very neatly with the > overwrite or append > >modes that we currently open the file with. I understand that the > >current situation is not very practical for file formats > that are not restartable (e.g. XML, HTML). > > > >Nicko > > > > > -----Original Message----- > > > From: Matthew Easlea [mailto:[EMAIL PROTECTED] > > > Sent: 07 June 2004 23:42 > > > To: 'Log4NET User' > > > Subject: RE: XML Layout > > > > > > Thanks Nicko, > > > > > > I can understand where you are coming from with keeping the > > > XMLLayout generating only the fragments. However, imagine the > > > following: > > > > > > <appender name="RollingFile" > > > type="log4net.Appender.RollingFileAppender"> > > > <file value="c:\\example.xml"/> > > > <appendToFile value="true"/> > > > <preMessage value="<?xml > version="1.0" ?> > > > > > > <!DOCTYPE log4net:events SYSTEM > > > "log4net-events.dtd" [<!ENTITY data SYSTEM > > > "abc">]> > > > > > > <log4net:events version="1.2" > > > xmlns:log4net="http://log4net.sourceforge.net/"> > > > "/> > > > <postMessage value="</log4net:events>"/> > > > <maximumFileSize value="50KB"/> > > > <maxSizeRollBackups value="2"/> > > > > > > <layout type="log4net.Layout.XMLLayout"> > > > <conversionPattern value="%p %d > [%t] - %m%n"/> > > > </layout> > > > </appender> > > > > > > As you can see I've added 2 appender parameters called preMessage > > > and PostMessage. Each time the rolling file appender > creates a new > > > file it would put the preMessage at the top and when it closes a > > > file and moves onto the next one it would put a > postMessage at the > > > end of the file. The preMessage could be used for other > things such > > > as help messages or copyright messages as well. It is thus > > > independent of the layout used. > > > > > > Does this sound like a reasonable solution? Do you think > it could be > > > implemented and if I were to implement it would the log4net > > > community be interested in such an enhancement? > > > > > > Matthew James Easlea > > > > > > > > > -----Original Message----- > > > From: Nicko Cadell [mailto:[EMAIL PROTECTED] > > > Sent: Monday, 7 June 2004 10:17 AM > > > To: 'Log4NET User' > > > Subject: RE: XML Layout > > > > > > The XmlLayout generates XML Fragments for each message. > XML does not > > > lend itself too well to a streaming format. > > > > > > When using the XmlLayout with the FileAppender or > > > RollingFileAppender the file written will not be a valid XML > > > document. It is a valid XML fragment. > > > However it can be included in a document. > > > > > > The output of the XmlLayout consists of a series of log4net:event > > > elements. > > > It does not output a complete well-formed XML file. The output is > > > designed to be included as an external entity in a > separate file to > > > form a correct XML file. > > > > > > For example, if 'abc' is the name of the file where the XmlLayout > > > output goes, then a well-formed XML file would be: > > > > > > <?xml version="1.0" ?> > > > > > > <!DOCTYPE log4net:events SYSTEM "log4net-events.dtd" > > > [<!ENTITY data SYSTEM "abc">]> > > > > > > <log4net:events version="1.2" > > > xmlns:log4net="http://log4net.sourceforge.net/";> > > > &data; > > > </log4net:events> > > > > > > This approach enforces the independence of the XmlLayout and the > > > appender where it is embedded. > > > > > > > > > Nicko > > > > > > > -----Original Message----- > > > > From: Matthew Easlea [mailto:[EMAIL PROTECTED] > > > > Sent: 06 June 2004 23:46 > > > > To: 'Log4NET User' > > > > Subject: XML Layout > > > > > > > > Hi, > > > > > > > > When I use XMLLayout using the rolling file appender is > > > there anyway > > > > for it to create valid XML files. By this I mean with > opening and > > > > closing <?XML> tag etc? > > > > > > > > Cheers > > > > > > > > Matthew James Easlea > > > > > > > > > > > > > > > > > > > > -- > Ceki G�lc� > > For log4j documentation consider "The complete log4j manual" > ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp > >
