On Feb 19, 2010, at 9:07 AM, Bruno Melloni wrote: > I know I'll again be writing a unified DailyRollingFile/RollingFile appender > for my current job in the future. > > Is there any chance to get it included into the main distribution if I > contribute it? If yes, what standards would it have to adhere to? > > I would rather contribute it than keep rewriting it every time I change jobs. > And my current company is probably the first that I'm working at that would > not object to me contributing a piece of code like this one even though it > would be built on their clock. > > b. >
Thanks for the interest to contribute to the project. There are a lot of issues that could overwhelm if I threw them all at you. Be happy to guide you through the issues at the proper time. However, as you describe it, my first concern is that you would have the ability to make a grant of the software to the ASF. Many times the employer retains rights to all code developed by their employees in the course of performing their duties. You'd need to look at the icla at http://www.apache.org/legal to see if you can agree to its terms. The second concern is that the software be developed in community. We are much more likely to accept software that was discussed on the list prior to the start of coding. The ASF is about software developed in an open collaborative manner. It can digest code developed outside of a community and has a whole project, the ASF incubator, to bring such code into the ASF, but it takes a lot of effort to make sure that every i is dotted and t is crossed. First, have you checked out Simon Park's the time and size rolling appender at http://www.simonsite.org.uk/? The current RFA in the log4j suite of RFA's run two serious risks: 1) They rename files, an action which is significantly different between Windows (open file blocks rename) and Unix (rename proceeds and user of open file has no clue). Also, short of new features in JDK 7, rename failures give no indication why they failed. 2) They close the old file before opening the new file. You can be stuck in a state where you may not be able to open the new file or reopen the old file (say if permissions were changed). It has been on my wish list for a long time to have an alternative to the current suite of RFA's based off the framework of MultiFileAppender that has been dormant in the sandbox for a while. Since MFA inherently supported having multiple files open at the same time, it should not be difficult for it to keep the old file open until the new file is acquired. http://issues.apache.org/bugzilla/show_bug.cgi?id=45165 also search the archives for MultiFileAppender for some previous discussion. If you were to build something that actually rolled, I would recommend that you build off the org.apache.log4j.rolling.RollingFileAppender. It was the "new" RFA in the abandoned log4j 1.3 development, not backported to log4j 1.2 and packaged in the extras companion (http://logging.apache.org/log4j/companions/extras). If is a common RFA with policies that identify when to trigger the rollover and how to rename and/or compress the files. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
