Hi Remko,

Yes this is exactly what I was looking for, and it does save me a large amount of effort. thanks you very much for the very useful feedback.

Regards
Peter

________________________________________
From: Remko Popma [remko.popma@gmail.com]
Sent: 07 February 2014 18:15
To: Log4J Users List
Subject: Re: Loading multiple different xml configuration files from different components within process

Peter,

I did not fully understand what you are trying to achieve, so I may be
completely off the mark, but are you aware that Log4J supports XInclude for
XML configurations? See also:
https://issues.apache.org/jira/browse/LOG4J2-341

This may be much, much easier than trying to approach this programmatically.

Hope this helps,
-Remko




On Wed, Feb 5, 2014 at 7:24 PM, McCarthy, Peter (Peter)
<petermc@avaya.com>wrote:

> Sorry folks,
>
> The commented out bit of code in first post may be misleading. I have
> corrected it below. When I use the command line -Dlog4j.configurationFile,
> I leave the static block out of the program.
>
> Again all help appreciated...
>
> Regards
> Peter
>
> -----Original Message-----
> From: McCarthy, Peter (Peter)
> Sent: 05 February 2014 09:34
> To: Log4J Users List
> Subject: Loading multiple different xml configuration files from different
> components within process
>
> 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;
>
>         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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org