> -----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.
I was going to add some more info to bug 11446 about this. > 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. Assuming that the header text has not changed between programme runs. It is safe to assume this. The appender could open the file and compare the head of the file with the header text. What the appender would do if it didn't match is another question. > 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.) How inaccurate is it? If the file size is near the length of the header you could do a byte by byte read to get the actual length. If it is very inaccurate then this may not be feasible. > 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. My issue with this approach is that the problem occurs with the FileAppender as well as with the rolling file appender. If the user wants a valid XML file and is using the FileAppender in append mode to generate the log file, then they would expect that the file would be valid XML every time their application exists. If the footer is not written when the appender is close this will never be the case. The only solution is to append the footer to the file each time the file is closed. This footer will have to be removed when the file is reopened. The cost of this may be relatively high. It also does not seem to be in the spirit of an _appending_ file appender. Fixing this for the FileAppender will also fix it for the rolling case. Nicko > > 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 > >
