You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-user@logging.apache.org by Fa...@nucorsteel.com on 2004/07/23 22:25:48 UTC
DailyRollingfileAppender / Chainsaw
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 code
but was not able to find anything. If it currently is not possible, I'd
like to implement it myself but I need a little bit of guidance as to where
exactly to put the option (FileAppender ?)
2) is there any work being done on communication with Chainsaw ?
3) Is there a possibility of having conversion character(s) for uptime
other than milliseconds ?
Any helpful feedback appreciated.
Thanks,
Alex
Re: DailyRollingfileAppender / Chainsaw
Posted by Christophe de Vienne <cd...@alphacent.com>.
Christophe de Vienne wrote:
> Does log4j 1.2.8 has more features than 1.2.0 ? or the 1.2.8 is a
> maintenance release ?
Sorry to answer myself, but I found this which answer the question :
http://cvs.apache.org/viewcvs.cgi/logging-log4j/docs/HISTORY?rev=1.109&view=markup
It appear that between 1.2 and 1.2.9 there is mostly bugfixes. So my
proposition make sense.
> In the last case, I'd suggest next log4cxx being versionned 1.2.0,
> since it will propose the same features than log4j 1.2.x which is the
> 'master' project. This will make the relation and inter-operability
> between both projects more clear.
>
> My 2 cents,
>
> Christophe
>
>
Re: DailyRollingfileAppender / Chainsaw
Posted by Christophe de Vienne <cd...@alphacent.com>.
Michaël CATANZARITI wrote:
> 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.
Does log4j 1.2.8 has more features than 1.2.0 ? or the 1.2.8 is a
maintenance release ? In the last case, I'd suggest next log4cxx being
versionned 1.2.0, since it will propose the same features than log4j
1.2.x which is the 'master' project. This will make the relation and
inter-operability between both projects more clear.
My 2 cents,
Christoàpeh
Re: DailyRollingfileAppender / Chainsaw
Posted by Fa...@nucorsteel.com.
About DailyRollingFileAppender again:
here's what Ceki says about the issue:
[start quote]
>This is a feature which has been requested several times in the past. It
>will probably implemented in log4j 1.3. Please see the o.a.l.rolling
>package for details for the new strategy-based code which will replace
>older and less flexible implementation. (The older code is likely to be
>removed in later releases of log4j, but not in the short term.)
[end quote]
I asked to get more details on exact implementation of , but did not get a
response yet. My best guess is that maxBackupIndex member would be
introduced in DailyRollingFileAppender and rollOver re-implemented in a
similar fashion as the RollingFileAppender one, so it should not be a huge
intervention into the code. I may be missing something important, so
please correct me if I'm seeing things in a too simplistic way.
Is waiting on log4j my only option (other than doing it just for myself
and then patching future versions after download)? Is there a way that we
can implement a feature and propose it back to log4j? If Ceki is following
this list it'd be nice to hear more from him on the topic.
Thanks,
Alex
P.S.
Chainsaw works fine with log4cxx and XML appender. I use it like this :
[CLIENT] [SERVER]
[process + socket appender] -> [simple socket server + xml appender] ->
chainsaw
I'm guessing it saves some network traffic to have socket server in
between - provided it's on the same machine with chainsaw.
> 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
Re: DailyRollingfileAppender / Chainsaw
Posted by Curt Arnold <ca...@houston.rr.com>.
On Jul 26, 2004, at 6:38 AM, FabijanicA@nucorsteel.com wrote:
>> public) from Ceki Gulcu mentioned that DailyRollingFileAppender had
>> been
>> deprecated in log4j in preference for RollingFileAppender.
>
> Does this mean that DailyRollingFileApender is going to be removed from
> log4cxx ?
>
I have not been able to find a mailing list discussion on the decision
to deprecate DailyRollingFileAppender. It would indicate that
DailyRollingFileAppender might be removed in log4j 1.5 or so and
alternatives should be considered.
>>> 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.
>
>> 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.
>
> Yes, days, hours and minutes would be a good solution.
>
Okay. I wanted to understand what you were thinking. If you want
this mainstream log4cxx, the best process would be to raise this an a
potential enhancement to log4j and see if you can get it in there.
However, that process could take quite a lot of time before it trickles
into log4cxx. I haven't looked to see if the PatternLayout provides
hooks for user added format specifiers, but if not we might look at
making it a little easier to do.
Re: DailyRollingfileAppender / Chainsaw
Posted by Fa...@nucorsteel.com.
> public) from Ceki Gulcu mentioned that DailyRollingFileAppender had been
> deprecated in log4j in preference for RollingFileAppender.
Does this mean that DailyRollingFileApender is going to be removed from
log4cxx ?
>> 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.
> 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.
Yes, days, hours and minutes would be a good solution.
Alex
Re: DailyRollingfileAppender / Chainsaw
Posted by Michaël CATANZARITI <mc...@apache.org>.
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
Re: DailyRollingfileAppender / Chainsaw
Posted by Curt Arnold <ca...@houston.rr.com>.
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.
>> 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.
>
> 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.
Re: DailyRollingfileAppender / Chainsaw
Posted by Fa...@nucorsteel.com.
Curt Arnold
<carnold@houston.
rr.com> To
Log4CXX User
07/23/2004 05:12 <lo...@logging.apache.org>
PM cc
Subject
Please respond to Re: DailyRollingfileAppender /
"Log4CXX User" Chainsaw
<log4cxx-user@log
ging.apache.org>
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...
>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.
>> 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.
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 ...
Alex
Re: DailyRollingfileAppender / Chainsaw
Posted by Curt Arnold <ca...@houston.rr.com>.
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
> code
> but was not able to find anything. If it currently is not possible, I'd
> like to implement it myself but I need a little bit of guidance as to
> where
> exactly to put the option (FileAppender ?)
>
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.
RollingFileAppender has a MaxBackupIndex that limits the number of log
files.
Another approach would be to make DailyRollingFileAppender::rollOver
virtual, then you could extend the appender and add your own action on
roll-over.
> 2) is there any work being done on communication with Chainsaw ?
I assume that you are talking about Socket communication with Chainsaw.
log4cxx's serialization of LoggingEvent is not currently compatible
with log4j's. There have been previous discussion on this list about
modifying the LoggingEvent serialization so that it would interoperate
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.
>
> 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.