logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: Using log4j1.2.17 foter is not getting added to each log file in rollingfileappender
Date Tue, 05 Jan 2016 22:51:47 GMT
Thanks for raising these issues. In addition to Gary's response, can I ask
some more questions to clarify?

1. Does LOG4J2-1101 <https://issues.apache.org/jira/browse/LOG4J2-1101> capture
your first requirement for a date in the pre-rollover file name?
3. I believe you are already verifying the fix for LOG4J2-908
<https://issues.apache.org/jira/browse/LOG4J2-908>, so that's in progress.
4. I commented on your ticket LOG4J2-1244
<https://issues.apache.org/jira/browse/LOG4J2-1244> for the custom
header/footer, let us know if that won't work.
5. Decoupling file pattern from rollover frequency can be achieved with
CronTriggerPolicy
<http://logging.apache.org/log4j/2.x/manual/appenders.html#TriggeringPolicies>
since 2.5. Does this do what you have in mind? (You mention LOG4J2-573
<https://issues.apache.org/jira/browse/LOG4J2-573>, but it looks like that
ticket is about something else, unless I misunderstand).
6. Custom log fields, are these items that cannot be covered with Lookups
<http://logging.apache.org/log4j/2.x/manual/lookups.html> or ThreadContext
(MDC) <http://logging.apache.org/log4j/2.x/manual/thread-context.html>
values? Like Gary, I'd like to understand better.


On Tue, Jan 5, 2016 at 4:04 PM, Anshu Garg1 <anshugarg@in.ibm.com> wrote:

> Hi Ralph,
>
> We  have actually tried log4j2, but unfortunately with that also we could
> not meet our requirements
>
>  We are trying a JSON log using rolling file appender based on both time
> and size but we are facing below challenges
>
> 1. Apache log4j2 default roll over implementation adds time stamp to log
> file name  while saving and closing, while our requirement is to add time
> stamp to file name at the time of file creation. For this we implemented
> our own rollover strategy. But that was not a complete solution since
> first file name was saved in rolling file appender without time stamp and
> to change that we extended "AbstractOutputStreamAppender" to create our
> own RollingFileAppender (but most of code in it is from Apache, except
> what we had to modify to set first file name with time stamp).
>
> http://stackoverflow.com/questions/30059333/log4j2-rolling-appender-filename-sliding-according-to-pattern
>
>
> http://stackoverflow.com/questions/14862770/log4j2-assigning-file-appender-filename-at-runtime
>
>
> 2. Above lead to mismatch between  the type of parameters in various other
> classes' methods where default Apache classes' types  were expected  but
> we were using our own implementation. So we had to use source code for
> such classes as is and just replace parameters' types from default to our
> implemented classes.
>
> 3. By default JSON Layout from Apache log4j2 has a non resolved defect
> which does not write a valid JSON. Log entries do not have a comma between
> then which results in invalid JSON. To rectify this we implemented our own
> layout. This again has most of the code from Apache but few changes here
> and there to get comma at start of each entry except first.
> https://issues.apache.org/jira/browse/LOG4J2-908
>
> 4. We had to customize header and footer values as per our requirement,
> since default in Apache default header is "[" and footer is "]". While we
> needed more information in header section.
>
> 5. With Apache log4j2's default behavior for time based rollover
>  duration's unit was determined by file pattern. We had to make duration
> time unit independent of file pattern because with default behavior  if a
> user wanted time stamp in file name till mili seconds then even file
> rollover would happen in mili seconds which is not desired. And if user
> wanted hourly or daily roll over then file stamp could only be used till
> date or hour. To be able to specify duration in a definite unit (minutes
> in our case) we had to implement our own PatternProcessor.
> https://issues.apache.org/jira/browse/LOG4J2-573
>
> 6. We needed to add some custom log fields in JSON logs for which we had
> to write our own LogEntry and MessageFactory.
>
> All above needed to write own classes with most functionality copied from
> Apache which means we could not achieve above with just extending the
> Apache classes. We had to make source code changes which we want to avoid.
> Do you have any suggestion to overcome above without having to fork code
> of Log4j2 ?
>
> We did not find any solution to above so we came back to Log4j1. Is there
> a way round to get footer in Log4j1 or Log4j2,  with above requirements,
> without having to change source code ?
>
>
> -Thanks & Regards,
> Anshu Garg
> Platform Technology Center, India
>
>
>
>
>
> From:   Ralph Goers <ralph.goers@dslextreme.com>
> To:     Log4J Users List <log4j-user@logging.apache.org>
> Date:   01/05/2016 12:04 PM
> Subject:        Re: Using log4j1.2.17 foter is not getting added to each
> log file in rollingfileappender
>
>
>
> Please see
>
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> <
>
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> >.
>
> Ralph
>
> > On Jan 4, 2016, at 11:14 PM, Anshu Garg1 <anshugarg@in.ibm.com> wrote:
> >
> > Hi,
> >
> > We have extended patternlayout to set custom footer and header. Now when
>
> > we use this pattern in rolling file appender footer is only added to
> last
> > log file generated while header is added to all files. Our requirement
> is
> > to have footer also added to files created. Any suggestion? Here is the
> > snippet.
> >
> > Logger logger = Logger.getLogger("myLogger");
> > CustomPattern pattern = new CustomPattern();
> > pattern.setHeader("HeaderText");
> > pattern.setFooter("FooterText");
> > rollingFileAppender.setLayout(pattern);
> >
> > -Thanks & Regards,
> > Anshu Garg
> > Platform Technology Center, India
> >
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message