Bug 36384 - Configuring triggering/rolling policies should be supported through properties
Configuring triggering/rolling policies should be supported through properties
Product: Log4j
Classification: Unclassified
Component: Configurator
Other Linux
: P2 normal
: ---
Assigned To: log4j-dev
Depends on:
  Show dependency tree
Reported: 2005-08-26 18:17 UTC by Jak Mang
Modified: 2008-08-11 14:40 UTC (History)
3 users (show)

patch to log4j's PropertySetter agaisnt today's code in trunk (3.82 KB, patch)
2008-08-06 09:06 UTC, Hugues Pisapia
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jak Mang 2005-08-26 18:17:09 UTC
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:

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

and later

Please set a TriggeringPolicy for the RollingFileAppender named 'foo'
Comment 1 Elias Ross 2007-01-28 03:37:55 UTC
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
Comment 2 Curt Arnold 2007-01-28 21:00:08 UTC
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.
Comment 3 Thorbjørn Ravn Andersen 2008-07-03 14:08:26 UTC
This is reported against 1.3alpha which has been discontinued.  Is this behaviour backported to 1.2 or should this be closed with WONTFIX?
Comment 4 Thorbjørn Ravn Andersen 2008-08-02 09:41:42 UTC
No response in a month.  Changing to NEEDINFO.
Comment 5 Hugues Pisapia 2008-08-05 02:58:10 UTC
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.
Comment 6 Curt Arnold 2008-08-05 16:47:50 UTC
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. 
Comment 7 Hugues Pisapia 2008-08-06 09:06:09 UTC
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.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.
Comment 8 Curt Arnold 2008-08-11 14:40:43 UTC
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.