The files are rolling, but it often lack a header/footer to make it usable in many software. Example, a csv pattern would be defined, but the column names header would need to be written on top of each file upon creation. Actually, the full feature is more like addind header and footer to the log file. To support multiline headers, the log4j property file should merely accept \n and/or \r (which I think java.util.Properties already supports).
*** Bug 40350 has been marked as a duplicate of this bug. ***
*** Bug 40349 has been marked as a duplicate of this bug. ***
Just a warning for developers, there seems to be a set header and set footer on some appenders, but although these methods exist, they do not perform the required task. Meanwhile, it is not always a matter of writing the header when the appender opens, and the footer when the appender closes. It is sometimes a matter of producing a file that has only 1 header and/or only 1 footer. This means the appender must open and read the file before being ready for appending it. Overall, there is the following desired features: -inject a header when appender is opening -inject a header when file is opening -inject a footer when appender is closing -inject a footer when file is closing (with the garanty that there wouldn't be any further appending) Therefore I suggest the following distinct attribute: a) file header b) session header c) session footer d) file footer Implementation of b) and c) are trivial. For the implementation of a), it is not really time consuming to read the beginning of the file to detect the existence of the file header. It could be only to test if file is of length>0, unless you can find any reason not to implement it this way first. After all the appender could be using a tight binary format, with a header of 1 byte! For the implementation of d), it is possibly a performance tax to read the file to discover if a footer exists (not to mention the difficulty to prove the end of the file is a footer and not data), in order to remove it and append over there. The behavior in presence of an existing footer could be left to the implementor of the header/footer-able-appender subclass: -never append an existing file and always roll to another file -test for perfect equality between intended footer and existing tail part of file -etc...