While attempting to try the new RollingFileAppender I ran into problems where I
could not set the rollingPolicy/triggeringPolicy from a properties file.
I wasted quite a bit of time trying permutations and searching the web.
Later I found this link:
http://mail-archives.apache.org/mod_mbox/logging-log4j-user/200309.mbox/%3c5.2.1.1.0.20030923153840.025f3850@mail.qos.ch%3e
I believe that the following corrections should be made:
1) Properties should be fully supported. Many people do not want to load and
run an XML parser just to read small 50 line config files.
2) Documentation should be clear on what is and is not supported.
3) It would help to have a tool/option/trace that would express the properties
and probably the XML attributes that are supported for particular component.
I turned on log4j.debug and got the less than helpful:
Failed to set property [triggeringPolicy] to value
"org.apache.log4j.rolling.TimeBasedRollingPolicy".
and later
Please set a TriggeringPolicy for the RollingFileAppender named 'foo'

1) Putting log4j.xml in your classpath is sufficient
2) Care to contribute? Not sure I understand the deficiency.
3) Properties of an appender are now logged (as debug) for SVN trunk
This needs to be a bug report, not a list of complaints

I'm going to reopen this one. Basically the deficiency is that every other included appender with the
exception of the org.apache.log4j.rolling.RollingFileAppender can be configured by either the
PropertyConfigurator or the DOMConfigurator while the new RFA can only be configured by the
DOMConfigurator. If you have an existing property file configuration and decide to extend it to include a
o.a.l.r.RFA, then you would have rewrite the whole configuration as an XML configuration file.
This is similar to https://issues.apache.org/jira/browse/LOGCXX-102 which includes a patch to log4cxx
to support configuration of o.a.l.r.RFA through the property configurator. While I have some issues with
putting RFA specific code in PropertyConfigurator (as the patch does), it does show that it is not
technically insurmountable to modify property configurator to support the new RFA. My preferred process
would be to come up with a fix in log4j and then port the fix over to log4cxx.

I've been fighting for a couple of days with the propertyconfigurator to try to have this working when I finally found this bug. Our project has a lot of log files, and of course, every thing is configured with properties. So updating all the configuration files into XML is a project in itself.
I have included apache-log4j-extras to try to have the RFA compressing the old log files when rotating along with log4j 1.2.14 without success. I would really love to have a fix included into 1.2 mainstream for this issue.
Apologies if this is not the right place to post.

The org.apache.log4j.rolling.RollingFileAppender is available for log4j 1.2 in the extras companion, so this issue is relevant to log4j 1.2. This is an issue that I'd be willing to accept a patch for, so I would not like to prematurely mark it as closed and prevent someone interested party to come up with a patch, but it isn't blocking since it is an enhancement and not a regression or some other critical issue.

Created attachment 22396[details]
patch to log4j's PropertySetter agaisnt today's code in trunk
Here is a quick patch I've been working on. It basically allows to configure the appender with an object by providing a class name and then configure the object via sub-properties.
I've been able to configure the rootLogger with the following properties:
#### ROOT category ###
log4j.rootLogger=DEBUG, ROOT
log4j.appender.ROOT=org.apache.log4j.rolling.RollingFileAppender
log4j.appender.ROOT.RollingPolicy=org.apache.log4j.rolling.TimeBasedRollingPolicy
log4j.appender.ROOT.RollingPolicy.FileNamePattern=/logs/root.log-%d{yyyy-MM-dd-HH-mm}.gz
log4j.appender.ROOT.File=/logs/root.log
log4j.appender.ROOT.layout=org.apache.log4j.PatternLayout
log4j.appender.ROOT.layout.ConversionPattern=%d{ABSOLUTE} [%t] %-5p %c - %m%n
And the log files was nicely rolling every minute and compressing the data. Also the mvn build was working fine (excepted for one test that was not passing before anyway).
I did not create a Unit test for that though. Point me in the right direction if you need one, and I'll find some time to create it.

Committed similar approach to submitted patch in rev 684948 along with unit test. Original patch could not be accepted since it changed the signatures on existing public methods.
Resolving as fixed, but reopen if there are problems.

This is ASF Bugzilla: the Apache Software Foundation bug system. In case
of problems with the functioning of ASF Bugzilla, please contact
bugzilla-admin@apache.org.
Please Note: this e-mail address is only for reporting problems
with ASF Bugzilla. Mail about any other subject will be silently
ignored.