;
> I am creating a new LoggerContext with task id as name. As application
> requests the loggers, I am creating the appenders and adding it to
> loggers. At the end of task, we basically close all the taks specific
> appenders. This works the way I want it to work. However
> method o
d for splitting logs
even more. Each class can request logger based on task id and type of log
and log to that logger.
I am creating a new LoggerContext with task id as name. As application
requests the loggers, I am creating the appenders and adding it to
loggers. At the end of task, we basicall
hreadContext.put("port", "someport")
logger.info("message from domain client");
logger.error("message form domain client error");
ThreadContext.remove("module");
ThreadContext.remove("hostname");
Th
in the
>>>> thread
>>>>> local object and based on the information I need to append a new logger
>>>>> object to the existing configuration object using
>>>> CompositeConfiguration
>>>>> and update
append a new
>>>> logger
>>>> > object to the existing configuration object using
>>>> CompositeConfiguration
>>>> > and update loggers in the logger context.
>>>> > I'm using the name of the logger object not to have a
t the line
>>> > logContext.reconfigure(compositeConfiguration);
>>> >
>>> > ERROR StatusConsoleListener Appender references must contain a
>>> reference
>>> > ERROR StatusConsoleListener Null object returned for AppenderRef in
>>&
> Logger.
>> > ERROR StatusConsoleListener No appender name provided
>> > ERROR StatusConsoleListener Could not create plugin of type class
>> > org.apache.logging.log4j.core.appender.SyslogAppender for element Syslog
>> > org.apache.logging.log
ll'
> > at
> >
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.injectFields(PluginBuilder.java:199)
> > .
> > at
> >
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:621)
>
value 'null'
> at
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.injectFields(PluginBuilder.java:199)
> .
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:621)
> at
> org.apache.logging.log4j.core.LoggerContext.rec
Null object returned for Syslog in Appenders.
Below is my implementation
ConfigurationBuilder builder1 =
ConfigurationBuilderFactory.newConfigurationBuilder();
AppenderComponentBuilder syslogAppender1 =
builder1.newAppender("syslog", "Syslog")
.addAttribute(&q
That's a good point.
Well... In between responses, I was excited to stumble upon a possible
silver bullet. There is a "disableAnsi" attribute on the pattern layout
[1]. Trying it on my file appenders, I can say most of my log files are now
without ANSI escape codes. That's goo
On Mon, Jun 10, 2019 at 4:55 PM Paul Benedict wrote:
> Pattern converters don't have the intelligence. I agree. However,
> converters don't exist for their own sake -- they exist for layouts and
> ultimately for Appenders. Those are the instances that have the
> intelligenc
Pattern converters don't have the intelligence. I agree. However,
converters don't exist for their own sake -- they exist for layouts and
ultimately for Appenders. Those are the instances that have the
intelligence to make sense out of themselves. Even more so is the Processor
to make se
> On Jun 10, 2019, at 12:18 PM, Paul Benedict wrote:
>
> To stop me hardcoding repetitive patterns in Appenders, I defined several
> elements as such. Most my Appenders go to files and a couple to
> the console. In addition, to prevent a multiplicity of plain-text vs. color
>
To stop me hardcoding repetitive patterns in Appenders, I defined several
elements as such. Most my Appenders go to files and a couple to
the console. In addition, to prevent a multiplicity of plain-text vs. color
text patterns, I defined color conversions in my patterns.
Clearly, this dual
I don't remember if there's a simpler way to do it, but the advanced way of
doing this would be using a RoutingAppender which delegates to those two
different appender refs you have.
You can also take a look at additivity which is related to what you're
asking about.
On 7 December 2017 at 06:10,
I want package com.abc.xyz to log only ERRORs to the console and INFO and
above to a file. How do I give the configuration in log4j2.xml for this?
Tried doing the below but didn't work.
ember 28, 2017 07:22
To: Log4J Users List
Subject: Re: Flushing async appenders
What version of Log4j2 are you using?
You can raise a JIRA ticket here: https://issues.apache.org/jira/browse/LOG4J2
(Shameless plug) Every java main() method deserves http://picocli.info
> On Nov 28, 2017,
similar positive metabolic effects.
-Original Message-
From: Remko Popma [mailto:remko.po...@gmail.com]
Sent: Tuesday, November 28, 2017 07:22
To: Log4J Users List
Subject: Re: Flushing async appenders
What version of Log4j2 are you using?
You can raise a JIRA ticket here: https
hilies) their kick, and boosts our metabolism, keeps immature fat cells
> from developing into full-fledged ones. And a recent study found that a
> compound in some sweet peppers (called CH-19 Sweet), which resembles
> capsaicin, provides similar positive metabolic effects.
>
> -
cent study found that a compound in
some sweet peppers (called CH-19 Sweet), which resembles capsaicin, provides
similar positive metabolic effects.
-Original Message-
From: Remko Popma [mailto:remko.po...@gmail.com]
Sent: Thursday, November 23, 2017 17:36
To: Log4J Users List
Subject: R
ur Rolling
file appender configuration. (See also
https://logging.apache.org/log4j/2.x/manual/appenders.html#RollingFileAppender
)
On Thu, Nov 23, 2017 at 11:42 PM, Laurent Hasson
wrote:
> Hello all,
>
> I have the following configuration file using async appenders. It works
> well but I
loggers
> were preferred performance-wise to async appenders. It describes a way to get
> async loggers through system properties, but I as trying to get that done
> through the configuration file. I tried the following, but do not get any
> logs output.
>
>
>
>
Hello all,
I have the following configuration file using async appenders. It works well
but I have one issue. During low-volume activity on my site, it seems that
nothing is output to the file, so it's hard to see what's going on. Same issue
happens while developing. But as soon
I saw on the log4j site
(https://logging.apache.org/log4j/2.x/manual/async.html) that async loggers
were preferred performance-wise to async appenders. It describes a way to get
async loggers through system properties, but I as trying to get that done
through the configuration file. I tried
x, y, z, etc modules, I have defined an appender
> and a logger. This made the xml too long and maintenance has become more
> and more difficult.
>
> I have some questions:
>
> 1. I had found out that multiple loggers
the xml by reducing both appenders and loggers?
3. Is it a feasible feature for log4j2 so that a logger can have multiple
names? (I am thinking about requesting the feature)
For example:
Regards,
sazzad
https://issues.apache.org/jira/browse/LOG4J2-1713
Thanks Gary
-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com]
Sent: Thursday, November 17, 2016 12:49 PM
To: Log4J Users List
Subject: Re: Copying appenders and loggers from a confgiruation to a builder
You need to
Duh! How did I miss that?
-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com]
Sent: Thursday, November 17, 2016 12:49 PM
To: Log4J Users List
Subject: Re: Copying appenders and loggers from a confgiruation to a builder
You need to click the red text in the "C
t there
> is no way to transfer loaded Configurtations to a Builder nor as there a
> way to generate XML from a built configuration.
>
> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Thursday, November 17, 2016 9:52 AM
> To: Log4J Users List
XML is a ConfigurationBuilder. But there is
no way to transfer loaded Configurtations to a Builder nor as there a way to
generate XML from a built configuration.
-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com]
Sent: Thursday, November 17, 2016 9:52 AM
To: Log4J U
November 17, 2016 9:52 AM
To: Log4J Users List
Subject: Re: Copying appenders and loggers from a confgiruation to a builder
Please feel free to record your feature request in JIRA:
https://issues.apache.org/jira/browse/LOG4J2
Gary
On Thu, Nov 17, 2016 at 7:47 AM, COHEN, STEVEN M wrote:
> Th
on file and having
> > read one of the to-be-combined configuration files into a Configuration
> > object, there appears to be nothing in the ConfigurationBuilder interface
> > that would allow, say, one of the appenders from the read-in
> configuration
> > to be copied, as a whole o
.
>
> I guess this would have to be a feature request, but in the meantime I
> might give CompositeConfiguration a try.
>
> -Original Message-
> From: Matt Sicker [mailto:boa...@gmail.com]
> Sent: Thursday, November 17, 2016 9:34 AM
> To: Log4J Users List
> Subj
: Thursday, November 17, 2016 9:34 AM
To: Log4J Users List
Subject: Re: Copying appenders and loggers from a confgiruation to a builder
I don't believe there is an API in ConfigurationBuilder that uses actual plugin
objects. That would certainly be a new feature. However, you did mention
comb
on
> object, there appears to be nothing in the ConfigurationBuilder interface
> that would allow, say, one of the appenders from the read-in configuration
> to be copied, as a whole object,into the builder, short of deconstructing
> it down to its constituent elements and adding th
unless I am
missing something:
Having created a ConfigurationBuilder for the destination file and having read
one of the to-be-combined configuration files into a Configuration object,
there appears to be nothing in the ConfigurationBuilder interface that would
allow, say, one of the appenders from
I succeed to reproduce the issue I was suspecting to happen :
https://issues.apache.org/jira/browse/LOG4J2-1441
2016-06-17 15:11 GMT+02:00 Anthony Maire :
> Hello
>
> As suggested in AsyncLogger javadoc, I made some performance tests on my
> application with (Rolling)RandomAccessFi
Hello
As suggested in AsyncLogger javadoc, I made some performance tests on my
application with (Rolling)RandomAccessFile appenders configured with
immediateFlush = false to take advantage of the potential I/O batching, and
the results are very good :)
However I have a question about the flush
After looking at SmtpAppender, SmtpManager and your eamil it doesn’t sound to
me like there is a lot of benefit in extending SmtpAppender or SmtpManager.
Their primary purpose of those, and the majority of the code, is to send email
- which you have said your version doesn’t do. The only code yo
Thanks for all your input.
I'm going to try and implement the appender we need to maintain our current
throttling infrastructure. I will send a patch with the changes we need as
far as moving items from private to protected and removing the final
keyword.
On Sat, Aug 30, 2014 at 2:02 PM, Matt S
http://logging.apache.org/log4j/2.x/manual/filters.html#BurstFilter
http://logging.apache.org/log4j/2.x/manual/appenders.html#RoutingAppender
There are several ways to go about implementing what you're asking about
using existing features. You may be able to get what you need by using just
the bur
It sounds like a feature that belongs to any logger. Syslog doesn't need to
know that a database server is unavailable every nanosecond, either.
Sent from my phone
> On Aug 30, 2014, at 3:19 AM, Remko Popma wrote:
>
> This sounds like a good feature to have in log4j2. I remember we had an issu
: Extending Appenders
This sounds like a good feature to have in log4j2. I remember we had an
issue at work where error logs were emailed automatically, bringing down the
mail server when the app kept generating the same error. Painful.
Sent from my iPhone
> On 2014/08/30, at 7:24, Michael Sch
This sounds like a good feature to have in log4j2. I remember we had an issue
at work where error logs were emailed automatically, bringing down the mail
server when the app kept generating the same error. Painful.
Sent from my iPhone
> On 2014/08/30, at 7:24, Michael Schall wrote:
>
> Again
Again, thanks for all the interest in my request.
I don't have the code in front of me, but I will try and give an
overview of what we did for log4j 1.x.
We want to send emails for errors happening in production. However for
example, we don't want to send thousands of emails if the network goes
d
This is a fair point. There are some things not in the API that we wouldn’t
change as they would also break compatibility, such as the Layout or Appender
interface, but we aren’t guaranteeing that specific Appender or Layout
instances won’t have a new parameter added to them or things like that
I would prefer to see changes that allows more flexible usage without
subclassing. If you subclass a core class, there is no guarantee that the
next release will be binary compatible. For the API, we do guarantee binary
compatibility within a major version.
Gary
On Fri, Aug 29, 2014 at 6:22 PM,
I would not object to changing SmtpAppender to make it more extendible.
Can you tell me more about your use case? SmtpAppender is designed this way
because we had a specific usage in mind. By understanding your use case we
might be able to improve the design in a way that benefits not just you but
Thanks for your response Remko.
Looking into this further, I could duplicate the SmtpAppender code as it
really just seems to do plugin work. The bulk of the code is in the
SmtpManager class which is not marked final. The constructor is marked
protected, however it takes a private class (FactoryD
Looks like this class was made final in January 2013. The commit message
mentions checkstyle errors.
What change are you proposing? Would just removing the final keyword from
the class definition be enough to fulfill your needs?
It may be good to raise this as a feature request in Jira.
If you nee
I'm upgrading an application to use Log4j2. With our existing
implementation we have created a new appender which extends the
SMTPAppender. I see the SMTPAppender is a final class now which prevents
me from extending it. I was wondering what the reason for this is? Do we
really need to re-imple
Yes, I'm programmatically adding appenders. I understand the point of view.
And what about having access to the properties of the appender as the
target of the ConsoleLogger? I know that this property is wrapped into an
OutputStream and into a OutputStreamManager but I think it could be ni
Are you programmatically adding the Appender?
I suggest the reconfiguration method because it allows for gracefully
switching to a new configuration. Some appenders need fields to remain
immutable for performance or safety reasons, so creating a new Appender on
reconfigure is generally the safer
Yes, I know that.
So if I have 10 LoggerConfigs that use the same Appender and I want to
change a property of this Appender, I should create a new one and update
the appender list (remove the old one and add the new one) of my 10
LoggerConfigs?
There isn't a simpler way, is there?
Clément
On Mon
If you reconfigure Log4j at runtime, you can switch over to a new
LoggerConfig without losing any messages. If you're holding direct
references to LoggerConfig, you should probably step back a level and get
that on demand instead.
On 25 August 2014 14:22, Clément Guillaume wrote:
> Hi,
>
> I wo
Hi,
I would love to have a direct access to the target of a ConsoleAppender (as
I can directly get the fileName of a FileAppender). Do you plan to
implement this feature ? (and also for others properties like
ConsoleAppender.isFollow or FileAppender.immediateFlush, ...)
I also would love to be a
oDb is the name.
> > >
> > >
> > > On 20 July 2014 13:44, David KOCH wrote:
> > >
> > > > Hello,
> > > >
> > > > I get this message:
> > > >
> > > > "Appenders contains an invalid element or attribute "N
tended?
>
> /David
>
>
> On Sun, Jul 20, 2014 at 8:55 PM, Matt Sicker wrote:
>
> > MongoDb is the name.
> >
> >
> > On 20 July 2014 13:44, David KOCH wrote:
> >
> > > Hello,
> > >
> > > I get this message:
> > >
>
o,
> >
> > I get this message:
> >
> > "Appenders contains an invalid element or attribute "NoSql"
> >
> > at start-up since switching from 2.0-rc1 to 2.0 when attempting to log to
> > Mongo. My configuration has not changed.
> >
&
MongoDb is the name.
On 20 July 2014 13:44, David KOCH wrote:
> Hello,
>
> I get this message:
>
> "Appenders contains an invalid element or attribute "NoSql"
>
> at start-up since switching from 2.0-rc1 to 2.0 when attempting to log to
> Mongo. My config
Hello,
I get this message:
"Appenders contains an invalid element or attribute "NoSql"
at start-up since switching from 2.0-rc1 to 2.0 when attempting to log to
Mongo. My configuration has not changed.
What's the new configuration name of the appender?
Thanks,
/David
OutputStreamManager.
You probably want to look at something like ConsoleAppender to see how a real
Appender works.
Ralph
On Jul 14, 2014, at 10:54 AM, dxande6 wrote:
> I've tried extending the appenders with the following code and keep getting
> errors:
>
> @Plugin(name =
I've tried extending the appenders with the following code and keep getting
errors:
@Plugin(name = "Stub", category = "Core", elementType = "appender",
printObject = true)
2.public final class StubAppender extends OutputStreamAppender {
3.
4.private Stub
First, your understanding is incorrect. You can attach appenders to any
logger, not just the root. Second, there must be some other stray log4j
config file being loaded, instead of this one, that logs to a file appender
pointing at the same file as the one in this log4j.properties.
I
Check out the additivity setting. Plus, check out Log4j 2.0 as that's what
we're all focused on right now!
On 11 July 2014 01:01, Vishal Pore wrote:
> My log4j.properties file is pasted below. My understanding is that we need
> to add Appenders to the *root *logger for the appe
My log4j.properties file is pasted below. My understanding is that we need
to add Appenders to the *root *logger for the appender to work. As you can
see in the below properties file, only appender A is attached to the root
logger (log4j.rootLogger=info, A). However, what I see is that the logging
That sounds more like a text editor at that point. Interactive /usr/bin/tail
On 4 June 2014 07:34, James Hutton wrote:
> Yeah, ideally there's a limit to the buffer in both choices, however why
> aren't you just logging to a file and using the jtextarea to display the
> file contents? Then you
Yeah, ideally there's a limit to the buffer in both choices, however why
aren't you just logging to a file and using the jtextarea to display the
file contents? Then you don't have as much a worry about memory usage.
On Jun 4, 2014 8:27 AM, "Gary Gregory" wrote:
> Note that you will shoot yoursel
Note that you will shoot yourself in the foot with such an appender by
causing memory to be exhausted unless the appender never lets the contents
of the text area grow beyond some limit.
Gary
On Mon, Jun 2, 2014 at 3:05 AM, Alex Wu wrote:
> Hi all, I have followed Ralph's suggestion in this is
Maybe have the appender be the owner of the jtextarea such that you could
call a gettextarea method when initializing your ui? Or you could buffer
until you call an initialize method with the jtext area. With the first
one not sure if you can write to the text area if it isn't in a frame, but
I'm
Hi all, I have followed Ralph's suggestion in this issue and the source
code of ConsoleAppender from apache to tried to create a custom appender
for appending logs to a JTextArea.
https://issues.apache.org/jira/browse/LOG4J2-303
But I am having trouble to make it to work, could anyone please give
On Thursday, February 6, 2014, McCarthy, Peter (Peter)
wrote:
> Folks,
> In documentation for Async appenders you state the following :
>
> "Asynchronous Appenders already existed in Log4j 1.x, but have been
> enhanced to flush to disk at the end of a batch (when the que
Folks,
In documentation for Async appenders you state the following :
"Asynchronous Appenders already existed in Log4j 1.x, but have been enhanced to
flush to disk at the end of a batch (when the queue is empty). This produces
the same result as configuring "immediateFlush=true"
Hi Ralph,
Any luck on this one?
For starters I'm just curious what the JSON setup would have to look
like to attach multiple appenders to a Logger.
Paul
On 10/7/2013 4:06 PM, Paul Bakker wrote:
Hi Ralph,
Tnx for looking into this.
Paul
On 10/7/2013 3:50 PM, Ralph Goers wrote:
I st
Hi Ralph,
Any luck on this?
Already have some insight as to how the JSON config file should look to
add multiple appenders to a single logger?
P
On 10/7/2013 3:50 PM, Ralph Goers wrote:
I started to try it last night but couldn't get it working correctly. I will
need to debug it.
and try it.
Ralph
On Oct 3, 2013, at 10:25 AM, Paul wrote:
Is it possible using the JSON config option to configure multiple
appenders on one logger?
The samples on
http://logging.apache.org/log4j/2.x/manual/configuration.html#JSON don't
really make this clear or I'm
Paul wrote:
>>
>> Is it possible using the JSON config option to configure multiple
>> appenders on one logger?
>>
>> The samples on
>> http://logging.apache.org/log4j/2.x/manual/configuration.html#JSON d
I'll have to create a test configuration and try it.
Ralph
On Oct 3, 2013, at 10:25 AM, Paul wrote:
> Is it possible using the JSON config option to configure multiple
> appenders on one logger?
>
> The samples on
> http://logging.apache.org/log4j/2.x/manual/configura
Is it possible using the JSON config option to configure multiple
appenders on one logger?
The samples on
http://logging.apache.org/log4j/2.x/manual/configuration.html#JSON don't
really make this clear or I'm missing it.
TIA,
P.
Hi Jake.
Thank you for explaining this very well. My motivation for having two
separate appenders that need to be tuned independently this way, is that I
need one log file/appender for debugging/analyzing and one for monitoring.
- The debugging log can in some periods be very verbose when doing
s say "com.myapp", for the INFO
level.
Now configure the ClassX and ClassY loggers for the DEBUG level.
Now your requirements get complicated. You need to configure filters for both
appenders so that:
1. AppenderB explicitly ignores anything but WARN+, except when logging for
ClassY, i
Hi.
No, I do not want to exclude the more severe logging levels, but I want to
enable more verbose logging for specific classes for appender A
independently of appender Bs logging of those same classes, and vice versa:
Appender A and B is defined.
Appender A is logging INFO+ for all by default, w
By default, if you set the level of a logger/appender to debug, it will
process debug, info, warn, error and fatal messages.
Is this what you want, or do you want to include only debug-level messages,
and exclude info, warn, error and fatal messages?
On Wednesday, October 2, 2013, fedinho wrote:
Thanks for your response Jacob.
I've been looking at the additive feature, but I'm not sure it solves my
requirement.
Given this configuration, I would like to debug class X on appender A, but
still keep the info level messages from class X on appender B.
I was hoping that this line would make t
On Tue, 1 Oct 2013 18:17:41 +0200
fedinho wrote:
Hi.
A simple question I hope someone can help me with. This is using log4j 1.2.x
I would like to log info level to one appender A and warn level to another
appenderB.
However, I would like to log debug messages from class X to appender A, and
Hi.
A simple question I hope someone can help me with. This is using log4j 1.2.x
I would like to log info level to one appender A and warn level to another
appenderB.
However, I would like to log debug messages from class X to appender A, and
debug messages from class Y to appender B.
Thanks fo
Sorry for being unclear. I've explained it better in this Jira comment:
https://issues.apache.org/jira/browse/LOG4J2-232?focusedCommentId=13648502&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13648502
From: Remko Popma [mailto:rem...@yahoo.com]
> Sent: Tuesday, July 30, 2013 2:09 PM
> To: Log4J-Users List
> Subject: Re: Are the custom appenders only like plugins?
>
> I see... Did you try pre-building the binary file with plugin descriptors
>
Sorry,
Do you mean binary file of my custom appender?
-Original Message-
From: Remko Popma [mailto:rem...@yahoo.com]
Sent: Tuesday, July 30, 2013 2:09 PM
To: Log4J-Users List
Subject: Re: Are the custom appenders only like plugins?
I see... Did you try pre-building the binary file with
I see... Did you try pre-building the binary file with plugin descriptors using
the PluginManager main method?
4.2.0 in my OSGi
application.
Any thoughs?
-Original Message-
From: Remko Popma [mailto:rem...@yahoo.com]
Sent: Tuesday, July 30, 2013 2:03 AM
To: Log4J Users List
Subject: Re: Are the custom appenders only like plugins?
Aliaksandr,
I don't think you need a specific OSGi version
Aliaksandr,
I don't think you need a specific OSGi version to make a plugin.
Remko
From: Aliaksandr Belavusau
To: log4j-user@logging.apache.org
Sent: Tuesday, July 30, 2013 5:27 AM
Subject: Are the custom appenders only like plugins?
Hi Guys,
T
Hi Guys,
Trying embed log4j2 in our OSGi application.
So, one small question: How can I create custom appender which will be
not a plugin? I want to create it like old school log4j1.x appender. The
cause: We cannot use osgi.core version >= 4.3.0 in our application, only
=4.2.0. (As you know 4
Hi Guys,
Trying to embed log4j2 in our OSGi application.
So, one small question: How can I create custom appender which will be
*not* a plugin? I want to create it like old school log4j1.x appender.
For the some reason we can not use osgi.core version >= 4.3.0 in our
application, only =4.2.0.
What is the recommended way of adding appenders in log4j 2.
In older version we were able to do
Logger.getLogger(theCategory).addAppender(appender).
Thanks!
On Tue, May 14, 2013 at 7:51 PM, Te Ta wrote:
> What is the recommended way of adding appenders in log4j 2.
>
> In older v
e a very "sledgehammer-like" approach.
>
> If you have something you can key on it would make more sense to use either
> a) configure both appenders and filter them based on the process.
> b) use the RoutingAppender to more or less do the same as option a but in a
> more
Doing what you have below seems like a very "sledgehammer-like" approach.
If you have something you can key on it would make more sense to use either
a) configure both appenders and filter them based on the process.
b) use the RoutingAppender to more or less do the same as option a but
Hi,
I've just converted a product to use log4j 2 and it is working well apart from
one thing.
The product has multiple processes e.g. processA and processB running on the
same host. I want them to use the same log4j.xml but write to different log
files e.g. processA.log and processB.log.
So I
I need log messages to appear in a log file without no more than a few
seconds of delay. I have set "immediateFlush" and "bufferedIO" to
force that, but still the messages only appear in the file when I shut
down the whole app. What am I missing here?
I'm using Log4j 1.2.15, org.apache.log4j.FileA
1 - 100 of 371 matches
Mail list logo
