You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by "McCarthy, Peter (Peter)" <pe...@avaya.com> on 2014/02/05 10:33:30 UTC
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;
// 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 <rg...@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 <re...@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 <ga...@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
> >> <re...@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 <ki...@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 <ar...@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
Re: Loading multiple different xml configuration files from different
components within process
Posted by Remko Popma <re...@gmail.com>.
Great! Glad to be of help.
Remko
On Monday, February 10, 2014, McCarthy, Peter (Peter) <pe...@avaya.com>
wrote:
> 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 <javascript:;>]
> 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)
> <pe...@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>
> >
RE: Loading multiple different xml configuration files from
different components within process
Posted by "McCarthy, Peter (Peter)" <pe...@avaya.com>.
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)
<pe...@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 <rg...@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 <re...@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 <ga...@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
> > >> <re...@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 <ki...@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 <ar...@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
Re: Loading multiple different xml configuration files from different
components within process
Posted by Remko Popma <re...@gmail.com>.
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)
<pe...@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 <rg...@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 <re...@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 <ga...@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
> > >> <re...@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 <ki...@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 <ar...@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
>
RE: Loading multiple different xml configuration files from
different components within process
Posted by "McCarthy, Peter (Peter)" <pe...@avaya.com>.
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 <rg...@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 <re...@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 <ga...@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
> >> <re...@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 <ki...@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 <ar...@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