Hello Fernando,
FYI, logback does starttls. See
http://logback.qos.ch/manual/appenders.html#SMTPAppender for details.
Fernando Wermus wrote:
I need to set up log4j to send emails using starttls. But I see there is a
lack of funcionallity for starttls. Have you upgraded log4j to
contemplate st
Hello,
Logback does exactly what you are asking for. It allows access to its
internal state via the StatusManager. Many of the unit tests in
logback verify the internal state. See
http://logback.qos.ch/manual/configuration.html#viewingStatusMessages
for documentation.
HTH,
ecmcn wrote:
Michae
Hello Jain,
Would you care to explain what is it that you are trying to accomplish?
sukesh jain wrote:
Hi all,
I searched the Bugzilla repository and also the log4j manual, with the text
"additional fields/info/properties" and "loggingEvent" but still did not found
any pointers specifying ho
Hello,
What kind of protocol are you using to write to the file servers? Is it NFS or
something else?
collatz wrote:
Hi there,
the DailyRollingFile appender is great for my needs. But there's one point:
I'm logging remote on a centralized repository. If I'm logging and my LAN
connection is
Hello Krishna,
If your application runs out of memory at an arbitrary point in code,
log4j will not be invoked, and cannot log. However, you also seem to
imply that log4j is somehow responsible for the runtime exception. In
that case, could you please be more specific?
Suresh Krishna wrote:
Hi,
DASHGIR wrote:
Do you know why log4j requires to log as remote? How does it do it. IP
spoofing?
Log4j does not require to log to a remote syslog host. *You* are telling it to
log through a SyslogAppender that *you* are defining.
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexib
DASHGIR wrote:
No error message, no output and the machine does not catch fire.
The hostname is indeed replaced with the machine hostname where the syslog
daemon is running.
I almost assumed that the syslog is setup to accept messages from the
network. I will check with the admins.
By defaul
Hi Lesley,
Looking at your log4j.xml file it appears that you are defining several
AsyncAppenders, actually 6 of them which does not explain why there are 12
AsyncAppender threads. At some point in time, you have probably restarted the
web-application (or reloaded log4j) without shutting down
Hello Lesley,
Thank you for the test case.
Indeed, multiple FileAppender instances located in the same JVM and writing to
the same file is a source of error. Just use a single FileAppender instance per
file target.
AsyncAppender uses references to appenders. It does not create them on its o
I bet that more than two application instances are writing to the same
log file. If you have such a requirement, try logback which supports
multiple JVMs writing to the same log file.
Lesley Tay wrote:
Hi all,
Wondering if anyone has tried running log4j 1.2.14 using Java 1.6.0_11?
Have you c
Hello Christophe,
SiftingAppender is prefect for this type of separation. See
http://logback.qos.ch/manual/appenders.html#SiftingAppender for more
information. If you intend to pursue this venue, please respond on the
logback-user mailing list. Do not respond here.
Christophe Elek wrote:
Hello,
The error means that you have two copies of log4j.jar loaded into memory at the
same time by two different class loaders. Classes loaded by different class
loaders are incompatible even if the classes are bitwise identical.
Pedro Moreno wrote:
So the error I get at the output is the followin
Hello Horatiu,
SiftingAppender is prefect for this type of separation. See
http://logback.qos.ch/manual/appenders.html#SiftingAppender for more
information. You would write a custom "discriminator" based on your
business flow object. If you intend to pursue this venue, please
respond on the log
Hello Augistin,
With logback's prudent mode, it is possible for multiple FileAppender
instances running on different JVM's to write to the same file. For
more information see the prudent mode of FileAppender:
http://logback.qos.ch/manual/appenders.html#prudent
According to our tests, prudent
Hello Arend,
The effect you are observing is most probably caused by multiple JVMs logging
into the same file.
Vogtländer, Arend (bos) wrote:
Dear Sir or Madam,
we have monitored a quite strage effect in log4j logfiles, which are
produced on a JBoss applicationserver of one of our customers
Hello,
Given that log4j is not designed for access logging, are you really
able to do access logging with log4j?
Chance Yeoman wrote:
> I am working on a log4j implementation of the http request logger for
> Jetty 6.1.7 and I had a question about the best practice for
> separating logger config
Hello Abhinay,
You should also have a look at SiftingAppender [1] which was specifically
designed to deal with cases such as yours. Just one extra line of code at the
start of your executor thread should be sufficient to address your problem.
SiftingAppender will do all the heavy lifting for y
Hello Thoralf,
The problem you are facing is probably related to the clean up code
Tomcat invokes when it redeploys web-apps. Replace commons-logging.jar
with jcl-over-slf4j.jar and your problem will go away. You need to add
slf4j-api.jar and slf4j-log4j.jar to you class path (in addition to
log4
Jacob Kjome wrote:
How so? Of course the libraries must use non-static loggers, but what else
prevents shared libraries from participating in a logger context where the
logging
implementation exists in the same (or parent) classloader?
Most libraries use static loggers. It would be nice if
Jacob Kjome wrote:
> Ceki Gulcu wrote:
>> It should not be difficult to write a SLF4J binding for log4j which
>> supports repository selectors.
>>
> ...which would require Log4j to directly implement the SLF4J interfaces, no?
> Doubtful for 1.2.xx.
If there is suppo
Hello Jacob,
Comments inline.
Jacob Kjome wrote:
Log4j 1.2.xx contains a RepositorySelector interface with no implementation and
no
well defined way of installing one. This was addressed in Log4j 1.3 (you must
recall, no?)... but that died on the vine. Ideally application containers would
Thanks for your response. Comments inline.
Jacob Kjome wrote:
Hi Ceki,
Can you please explain your change of heart first? I'll take a guess as to your
skepticism...
1. Very little built in support, making repository selectors generally a custom
solution, which inhibits widespread use. T
Hello Bender,
Thank you for your detailed response. I appreciate it.
I believe that the problem you describe, namely separation of logging
(per thread), can be accomplished by means other than repository
selectors.
Your requirements are duly noted. I intend to look into it and to offer a
more c
Hello,
I am in the process of fixing bugs related to context selectors in logback.
Context selectors are the equivalent of repository selectors in log4j. However,
while few years back I thought that context selectors, aka repository selectors,
were the wave of the future, I am increasingly skept
Hello Joe,
Have you considered logback? See
http://logback.qos.ch/manual/appenders.html#SMTPAppender
for documentation on SMTPAppender.
Joe White wrote:
I'm trying to use the SMTP Appender but my mail host requires
authentication.
What are the poper log4j.properties entry for usern
Vijendra Rai wrote:
[snip]
I can see additional logging messages coming into the server console
now, but it does not provide any indication of
why sometime logging stops. Can someone provide some ideas what I should
do next? Is this a Log4j bug?
Hello Vin,
It would probably help if you inclu
Hello Christian,
Thank you for taking the time to write a test case reproducing the problem. As
it stands, the problem arises from the fact that the two file appenders share
the same layout which is incorrect. Layouts are not meant to be shared.
HTH,
Christian Delbe wrote:
Hi,
I encounter
ck. Was it because you were not aware that they
existed, or was it some other reason?
Julius Davies wrote:
Here's a page of what I consider log4j best practises:
http://juliusdavies.ca/logging.html
Any comments are very welcome!
--
Ceki Gulcu
http://logback.qos.ch/
A generic, reliable,
Kristian,
Do wish to redirect your log4j calls to JDK logging? If so, you could use
log4j-over-slf4j, and then let SLF4J use JDK logging as the underlying logging
system by placing slf4j-jdk14.jar on your class path.
HTH,
[1] http://www.slf4j.org/log4j-over-slf4j.html
Kristian Rink wrote:
The root logger is set to WARN. That might be the culprit.
Jérôme Pramondon wrote:
log4j: Parsing for [root] with value=[WARN, stdout, file].
log4j: Level token is [WARN].
[snip]
--
Ceki Gülcü
QOS.ch is looking to hire talented developers in Switzerland. If
interested, please contact c e k
Hello Srijith,
You might want to try logback which is a significantly improved version of log4j
heavily based on Joran.
HTH,
Srijith Kochunni wrote:
Hi All,
I am working on a project using log4j for the first time so please excuse me if the question is too basic. I basically
Scott Deboy wrote:
What about the option of adding support for messageFormat in logger itself in a future release?
(which release?)
I think it's a good idea.
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
-
Curt Arnold wrote:
As Scott mentioned, the extras companion contains two utility classes to
support parameterized logging, LogSF and LogMF. LogSF uses the log4j
1.3 message patterns (curly braces, no argument count or qualifiers) and
LogMF which uses the java.text.MessageFormat. LogSF only j
Hi Dirk,
Have you considered using the SLF4J API? It supports log4j 1.2 as well as other
logging systems. Moreover, you would not need to change your code since SLF4J
supports parameterized syntax you are currently using.
HTH,
dirk ooms wrote:
Hi,
i was using log4j 1.3, but i am moving bac
Hello Kumar,
Since you have partially identifier the problem, couldn't you just use the same
version of log4j?
Prathib Kumar wrote:
Hi,
I m using Tomcat 5.5 and my web application uses 2 different versions(1.1.3 & 1.2.13) of log4j. I have placed one log4j under shared/lib folder and other i
You might want to consider logback which handles this task very nicely.
minimoe wrote:
Hi!
I've got a question regarding log4j and propagating errors in a program
flow. I'm currently developing test case scripts using Rational Functional
Tester which has a poor logging system and I've looked in
Hello,
Internal error handling is one of the strong points of logback, the purported
successor to log4j. Each logback component is attached to a context which
maintains a publicly accessible list of internal errors. Search for
StatusManager in logback documentation.
See also "Chapter 2 - Archite
geff henderson chang wrote:
Ceki:
Thanks for the response.
Sure.
I don't have any problems with using other log files.
My current situation is this.
I have different log4j.xml files for different modules.
For the error log, they all refer to the same error.log
But one of them specifies a
Hello Geff,
If both config files refer to the same log file the behavior is unspecified.
Thus, odd behavior you are observing is "expected".
Can you have the two config files refer to *different* log files?
geff henderson chang wrote:
Hello,
I have 2 different applications that refer to th
39 matches
Mail list logo
