logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "McCarthy, Peter (Peter)" <pete...@avaya.com>
Subject Loading multiple different xml configuration files from different components within process
Date Wed, 05 Feb 2014 09:33:30 GMT
Folks,

I am trying to programmatically configure multiple xml files as I want each sub system using
log4j2 to "own" its own configuration (As opposed to having them all in one monolithic block).

I have tried the code below with an xml that reconfigures the root logger to a separate file.
When I load the config file from the command line (-Dlog4j.configuration) everything works
fine. However when loaded using the code below, the output goes to the default root logger.
When I look at the log4j logs themselves it states that is has set up the root logger using
my appender, however the log statements do NOT go to my appender.

The relevant config is also included. Any help is greatly appreciated !!

Regards
Peter McCarthy

public class MyLogger {
    
    private static Logger logger;

    static {
        File logConfigFile = new File( "log4j2_SGM.xml" );
        try {
            FileInputStream fis = new FileInputStream( logConfigFile );
            /*
            XMLConfigurationFactory fc = new XMLConfigurationFactory( );
            fc.getConfiguration(  new ConfigurationFactory.ConfigurationSource( fis ) );
 
            URI configuration = logConfigFile.toURI();
            Configurator.initialize("config", null, configuration);
 
            org.apache.logging.log4j.core.LoggerContext ctx =
                    (org.apache.logging.log4j.core.LoggerContext) LogManager.getContext( true
);
            ctx.reconfigure();
            */
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        }
        
        logger = LogManager.getLogger(MyLogger.class);
    }
    
    /**
     * @param args
     */
    public static void main(String[] args) {
        int myNum = 0;
        // XMLConfiguration conf = new XMLConfiguration(null);
 

        while (true) {
            logger.error("Hello, World! ", myNum++);
            if ( myNum == 10 ) {
                break;
            }
        }
    }
    
}

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="all" dest="file://C:/Avaya/Logs/CCMS/log4j2.log">
  <Properties>
  	<Property name="AmlTransLogLoggingLevel">DEBUG</Property>
	<Property name="AmlTransLogLoggingLevel">DEBUG</Property>
	<Property name="AmlCilLogLoggingLevel">DEBUG</Property>
	<Property name="SipSpLogLoggingLevel">DEBUG</Property>
	<Property name="MaxLogFileSize">50 KB</Property>
	<Property name="MaxNumBackupFiles">5</Property>
  </Properties>
  <Appenders>
    <Console name="stdout" target="SYSTEM_OUT">
      <PatternLayout pattern="%d{dd/MM HH:mm:ss.SSS} [%-16.16t] %-5p %-30.30c - %m%n"/>
    </Console>

    <RollingRandomAccessFile name="SipSpLog" fileName="C:\\Avaya\\Logs\\CCMS\\CCMS_SGM_SipSp.log"
filePattern="C:\\Avaya\\Logs\\CCMS\\CCMS_SGM_SipSp%i.log" append="true" immediateFlush="false">
      <PatternLayout>
        <Pattern>%d{dd/MM HH:mm:ss.SSS} [%-16.16t] %-5p %-30.30c - %m%n</Pattern>
      </PatternLayout>
      <Policies>
        <SizeBasedTriggeringPolicy size="100 KB"/>
      </Policies>
      <DefaultRolloverStrategy max="5"/>
    </RollingRandomAccessFile>

  </Appenders>

  <Loggers>
  	<Logger name="logger" level="${SipSpLogLoggingLevel}">
  		<AppenderRef ref="SipSpLog"/>
  	</Logger>

   	 <Root level="debug">
     		 <AppenderRef ref="SipSpLog" level="debug"/>
    	</Root>
  </Loggers>
</Configuration>
-----Original Message-----
From: Gary Gregory [mailto:garydgregory@gmail.com] 
Sent: 04 February 2014 05:23
To: Log4J Users List
Subject: Re: rolling in log4j2

On Sun, Feb 2, 2014 at 7:49 PM, Ralph Goers <rgoers@apache.org> wrote:

> The actions originated with the Log4j1 extended design and code. I 
> started from that and then tried to merge the rollover strategies into 
> something that made sense to me. That doesn't mean it can't be changed.
>

It feels like a neat focused package. I would not like a generic 'helper'
package to become a dumping ground or kitchen sink for other stuff.

I think I'll change in the AM.

Gary


> Sent from my iPad
>
> > On Feb 2, 2014, at 12:11 AM, Remko Popma <remko.popma@gmail.com> wrote:
> >
> > Yes, I was thinking along similar lines.
> >
> > Something like https://issues.apache.org/jira/browse/LOG4J2-491
> > but perhaps more general.
> >
> > I haven't got it all worked out yet but I find the current 
> > DefaultRolloverStrategy difficult to unit-test. E.g., file deletes 
> > are
> not
> > actions, but renaming and zipping are actions.
> > It would be nice to separate the logic that generates the "action plan"
> > from the execution of that action plan. That would facilitate unit
> testing
> > and perhaps make it easier to let users insert their own actions in 
> > the chain. Determining deletion candidate files could be part of the 
> > logic
> that
> > generates the action plan.
> > Sorry if this all sounds a bit vague atm. Need to think about this 
> > some more...
> >
> >
> >> On Sunday, February 2, 2014, Gary Gregory <garydgregory@gmail.com>
> wrote:
> >>
> >> Perhaps a different approach would be to have a separate clean up 
> >> object that you give a pattern and an age. This would let you 
> >> separate the rollover concern from the clean up.
> >>
> >> Gary
> >>
> >>
> >> On Sat, Feb 1, 2014 at 11:02 PM, Remko Popma 
> >> <remko.popma@gmail.com>
> >> wrote:
> >>
> >>> I see. Basically, you are trying to avoid deleting files that were 
> >>> not
> >> the
> >>> result of a rollover, is that correct?
> >>> I don't have a good answer to that yet.
> >>>
> >>> Another use case is patterns like this:
> >>> filePattern="logs/%d{yyyy-MM}/app-%d{yyyy-MM-dd}.%i.log"
> >>> where the directory name is or contains a date pattern. So just 
> >>> using
> the
> >>> fixed text prefix part of the filePattern is not sufficient to 
> >>> achieve
> >> your
> >>> goal...
> >>>
> >>> Alternatively,
> >>> filePattern="logs/%d{yyyy-MM}/webapp42/app-%d{yyyy-MM-dd}.%i.log"
> >>> where the directory with the date pattern is not the parent 
> >>> directory
> of
> >>> the rolled over log files.
> >>>
> >>> So I thought we should limit the scan to the directory containing 
> >>> the rolled over log files...
> >>>
> >>> Obviously, if the parent directory is a pattern that changes every
> month,
> >>> having a "maxAge=2M" (2 months) would never result in a match if 
> >>> we
> only
> >>> scan the directory holding the rolled over log files, so older log
> files
> >>> would never get deleted. That should not be a problem though.
> >>>
> >>> Hm... The only way I can think of to avoid deleting files that 
> >>> were not
> >> the
> >>> result of rollover is by pattern matching on the name...
> >>> I was hoping to avoid that by simply defining the functionality as 
> >>> "any file in that directory is a candidate for deletion", but I 
> >>> guess this
> may
> >>> be surprising for users...
> >>>
> >>>
> >>>
> >>>
> >>>> On Sun, Feb 2, 2014 at 12:13 PM, Kireet <kireet@feedly.com> wrote:
> >>>>
> >>>> That wouldn't be ideal for me as I have several different log 
> >>>> files
> >> being
> >>>> produced in the same directory, but I do see how it would get 
> >>>> pretty complicated to pattern match old files to delete 
> >>>> selectively. I could separate things by folder I guess. What 
> >>>> about at least filtering the
> >>> files
> >>>> by everything up until the first pattern? E.g. for the below 
> >>>> "app-%d{yyyy-MM-dd}.%i.log", what about only deleting files that 
> >>>> start
> >>> with
> >>>> app- and are older than the maxAge?
> >>>>
> >>>>
> >>>>> On 2/1/14 6:59 PM, Remko Popma wrote:
> >>>>>
> >>>>> Agreed that this seems a common use case. Looking at the 
> >>>>> LOG4J2-435<https://issues.apache.org/jira/browse/LOG4J2-435>

> >>>>> ticket,
> >>>>>
> >>>>> you're now the third person asking for this feature...
> >>>>>
> >>>>> Team, what about adding a maxAge attribute to
> DefaultRolloverStrategy?
> >>> The
> >>>>> attribute would accept values like "3d" (delete older than 3 
> >>>>> days), similarly "4w" (4 weeks), "5M" (5 months) etc.
> >>>>> The scanned directory would be the parent dir of the rolled over

> >>>>> file specified by the {{filePattern}} attribute, and any file in

> >>>>> that
> >>> directory
> >>>>> would be candidates for deletion.
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>>
> >>>>> On Sunday, February 2, 2014, Arkin Yetis <arkinyetis@gmail.com>
> >> wrote:
> >>>>>
> >>>>> I had opened the following for this:
> >>>>>> https://issues.apache.org/jira/browse/LOG4J2-435
> >>>>>> Perhaps you can see if this would meet your need and vote 
> >>>>>> for/watch
> >> it,
> >>>>>> if
> >>>>>> it does.
> >>>>>>
> >>>>>>
> >>>>>> On Sat, Feb 1, 2014 at 11:39 AM, Kireet <kireet@feedly.com
> >>> <javascript:;>>
> >>>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Thanks for the update. So I would need to use an external 
> >>>>>> process to clean
> >>>>>>
> >>>>>>> up older files? This seems like a pretty common use case

> >>>>>>> though
> >> right?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 2/1/14 12:19 AM, Remko Popma wrote:
> >> --
> >> E-Mail: garydgregory@gmail.com <javascript:;> | ggregory@apache.org
> <javascript:;>
> >> Java Persistence with Hibernate, Second Edition< 
> >> http://www.manning.com/bauer3/> JUnit in Action, Second Edition 
> >> <http://www.manning.com/tahchiev/>
> >> Spring Batch in Action <http://www.manning.com/templier/>
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>


--
E-Mail: garydgregory@gmail.com | ggregory@apache.org Java Persistence with Hibernate, Second
Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Mime
View raw message