logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michaël CATANZARITI <mca...@apache.org>
Subject Re: DailyRollingfileAppender / Chainsaw
Date Sat, 24 Jul 2004 19:43:39 GMT


Curt Arnold wrote:
> 
> On Jul 23, 2004, at 4:41 PM, FabijanicA@nucorsteel.com wrote:
> 
>> On Jul 23, 2004, at 3:25 PM, FabijanicA@nucorsteel.com wrote:
>>
>>>> I have a few questions:
>>>>
>>>> 1) Is it possible to make DailyRollingFileAppender delete files older
>>>> than
>>>> n days (hours, mins,...)? I was looking for something like that in the
>>
>>
>>> As far as I can tell, that is a feature that is not currently in log4j.
>>>  I think the project in general would not be receptive to adding a
>>> feature that is not already in log4j.  However, if it is in log4j or if
>>> you can get it accepted for log4j, then I think that log4cxx could
>>> follow.
>>
>>
>> I know I need it if I am to use this library in real world. And I doubt
>> anyone else has an urge of manually deleting old files.
>> I can not imagine anyone would opose such a thing. But, then maybe I am
>> missing something important...
>>
> 
> 
> There have been a couple of log4j bugs (bugs 13947, 11907, 29835) that 
> appear related to these issues.  I assume there may be traffic on the 
> mailing list also related to this issue on log4j.  I haven't followed 
> them, but we would not want to address them in log4cxx in a different 
> way than log4j.  One of the comments on 13947 (which made rollover 
> public) from Ceki Gulcu mentioned that DailyRollingFileAppender had been 
> deprecated in log4j in preference for RollingFileAppender.
> 
> The log4j is more mature and has a more active community.  If there is a 
> problem with a proposal, it is much more likely to get a rigorous review 
> when proposed for log4j.  If somebody has a problem, that person more 
> likely to complain if it was proposed for log4j than log4cxx.
> 
> 

Log4cxx is still a young project. About the version 1.0 which is still in dvt, we've planned
to propose the same features as in log4j 1.2.8
At the present time, the log4j team is developing the version 1.3, but the new features of
this version will not be included in log4cxx 1.0
In the future, we hope all Apache logging sister projects will converge to offer the same
features.

> 
>>> RollingFileAppender has a MaxBackupIndex that limits the number of log
>>> files.
>>
>>
>> That is exactly what I need for DailyRolingFileAppender. I'll try to 
>> do it.
>>
>>> Another approach would be to make DailyRollingFileAppender::rollOver
>>> virtual, then you could extend the appender and add your own action on
>>> roll-over.
>>
>>
>> No, it does not feel right.
> 
> 
> One of the log4j bugs mentioned using that approach hence the complaint 
> about rollOver being private.
> 
> 
>>
>>>> 2) is there any work being done on communication with Chainsaw ?
>>
>>
>>> I assume that you are talking about Socket communication with Chainsaw.
>>> with log4j, however I don't know anyone working on it at this time.  A
>>> substantial part of the work would reverse engineering the binary
>>> format of log4j serialized LoggingEvent which should be moderately
>>> straightforward since Java serialization is documented and log4j is
>>> open source.

log4cxx can communicate with Chainsaw by using the XMLSocketAppender :
http://logging.apache.org/log4cxx/manual/classlog4cxx_1_1net_1_1XMLSocketAppender.html

>>
>>
>> I may give it a try one of these days.
>>
>>>> 3) Is there a possibility of having conversion character(s) for uptime
>>>> other than milliseconds ?
>>
>>
>>> Again, this is a place where I think that we would need to follow
>>> log4j's lead.
>>
>>
>> Not that I am trying to be smart, but my request is coming from a real
>> world need - I must be able to see right away a meaningful number for the
>> process uptime.
>>
>> Anyway, thanks for your precise and quick response. I've got some 
>> direction
>> now ...
>>
>>
> 
> I guess by meaningful, you mean formatted something like T1D4H33M?  I 
> wouldn't think "13.404 s" would be significantly more readable than 
> "13404 ms".  I haven't dug into this on the log4j bug or mailing list.
> 
> 
> 

Regards,

-- 
Michaël CATANZARITI
log4cxx project manager

	log4cxx user mailing list:
	mailto:log4cxx-user-subscribe@logging.apache.org

	log4cxx developer mailing list:
	mailto:log4cxx-dev-subscribe@logging.apache.org

Mime
View raw message