Colin,
log4j does not throw exceptions. However, the RollingFileAppender
-should- make calls to the errorHandler. Implement your own
ErrorHandler and you should be able to get those notifications.
Kevin
Colin MacDonald wrote:
Hi all! In my application, I need to know if log4j failed
LogEvents don't have fields for those items, and the JDBCAppender logs
LogEvent objects. So you'll have to do some coding.
A couple options off the top of my hand:
1) extend PatternLayout with conversion characters for all those things
2) override getLogStatement(...) in JDBCAppender.
3)
Raghu,
Below are three config files for the CompositeRollingAppender,
you'll be interested in the one at the bottom. You should change the
Category references to Logger (it's been a little while since I wrote
it). Hopefully this will work for you.
Kevin
#Config file for
Where you override getConnection()/closeConnection() you should call
errorHandler.error(...) when you have problems.
Bomb Diggy wrote:
Using the JDBCAppender by Kevin Steppe - the one
provided in the 'jdbc' package with 1.2.3. I've
overridden the getConnection() and closeConnection
Jon,
Please post to the users list only for this kind of question. Now
to answer your question:
try:
sql=insert into logtable (threads) values (%t)
For most databases you can use either , or ', for varchar fields. Use
the one not in the value. If both are in the value you have to do
is interpreting as schema objects resulting in an SQLException
ORA-00972 identifier is too long
-Original Message-
From: Ben Sandee [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 06, 2002 8:23 AM
To: Log4J Users List
Subject: Re: Log4j JDBCAppender
Kevin Steppe wrote:
Jon,
Please post
Ben Sandee wrote:
Kevin Steppe wrote:
[snip]
Kevin,
I agree it's not worth the effort -- primarily because for my projects
I don't want log data stored in a database anyway -- and I work at a
company historically known for it's database software! :-) (Sybase)
I do take issue
log4j version 1.2.0 released
I do have multiple log4j.jar files around, but all are of the same
version. There is reason to believe that I may have multiple different
versions of -my own- class files lying around that I should hunt down.
After some further hunting, the original exception
? Is it because your time is
more
precious then other's?
At 00:39 24.05.2002 -0700, Kevin Steppe wrote:
log4j version 1.2.0 released
I do have multiple log4j.jar files around, but all are of the same
version. There is reason to believe that I may have multiple
different versions of -my
When I use log4j to log message and stack info when
Class.forName().newInstance() fails I get an Error thrown. I thought
log4j was supposed to guarentee this didn't happen?
Here is the error:
java.lang.VerifyError: (class:
org/apache/log4j/spi/ThrowableInformation, method: getThrowableStrRep
Performance questions---
First off, databases are pathetically slow compared to file or memory
writes. If you have a performance critical application avoid a database
where-ever possible. Ironicly, this is true even for database driven
applications -- you'll get better performance by
a jdbc package... Is that
package
only in a nightly build release?
Mark
-Original Message-
From: Kevin Steppe [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 03, 2002 4:19 PM
To: Log4J Users List
Subject: Re: JDBCAppender in 1.2rc1
Ceki, could you yank my directory from the contribs
wrote:
I'm trying to compile the demo program for the Kevin Steppe JDBCAppender,
and it won't compile.
I get this message:
JDBCAppender.java [111:1] cannot resolve symbol
symbol : method setOption (java.lang.String,java.lang.String)
location: class org.apache.log4j.AppenderSkeleton
of preserving past heartbeats in
the heartbeat log. Maybe I'm just not used to it. How difficult would it be to
subclass Appender to create an Overwriting 'Appender'?
-Original Message-
From: Kevin Steppe [mailto:[EMAIL PROTECTED]]
Sent: Tue 4/30/2002 7:03 PM
To: Log4J Users List
Cc
Steve,
I would set up a special catagory/logger for heartbeats
(myapp.heartbeat.x, myapp.heartbeat.y, ...). Attach a FileAppender
to that category which will output the date-time of the logging. Then
watch the lastModified() date on that file. The lastModified will
change with every
of preserving past heartbeats in
the heartbeat log. Maybe I'm just not used to it. How difficult would it be to
subclass Appender to create an Overwriting 'Appender'?
-Original Message-
From: Kevin Steppe [mailto:[EMAIL PROTECTED]]
Sent: Tue 4/30/2002 7:03 PM
To: Log4J Users List
Cc
it's in: org.apache.log4j.jdbc.JDBCAppender line ~160
The cvs has the correct version.
Kevin
Nate Drake wrote:
At 07:56 24.04.2002 -0700, you wrote:
Hello,
I have used the JDBC Appender in the new log4j1.2-rc1
And i noticed the following:
1. It keeps on logging to the console,
A few ideas all around extending JDBCAppender
1) override the getConnection() method. In there you would contact your connection
handler (you might have to write one) and grab the active connection.
2) add a new method like:
public setConnection(java.sql.Connection c) {
connection = c;
}
Thomas,
That will be the design idea for improvements in the 1.3 version I'll be
working on. The idea is to separate the When and how do I change files? from
the implementation details of putting logging events into a files.
Kevin
Thomas Tuft Muller wrote:
Yeah, but the initiator wanted
Set up the JDBCAppender in your config. Then use log4j as you would with any other
appender. This is important because you should easily be able to change to logging
into a file, JMS sink, console, or database.
Here is an example properties file to set up the JDBCAppender as your root
I'd make an extension to PrintWriter that sends things to log4j. Something like:
class Log4jWriter extends PrintWriter
{
Logger log = Logger.getLogger(Log4jWriter for TOPLink);
public void println(String message)
{
log.debug(message);
}
}
Then:
session.setLog(new
Certainly... Use the JDBCAppender, it's in the cvs under package
org.apache.log4j.jdbc
Kevin
Han Solo wrote:
Hi:
I started to use the Log4J and I would like to
know if it is possible to use it to log into a
database instead of a filesystem?
Regads
Francisco Jaen Alegria
Quick answer from Kevin Steppe:
I am still supporting my version and answering questions. Last I asked
Thomas Fenner he was too busy to actively support his version. The now
official JDBCAppender (in org.apache.log4j.jdbc -- and which I wrote, though
Ceki made great improvements
Log4J doesn't necessarily violate the EJB spec --- configuring from a file or
outputting to a file does. If you want to use the FileAppender you'll need to
configure your server to allow access to files (I have no idea how to do that).
Alternatively you could use a JDBCAppender (in cvs under
I wrote a CompositeRollingAppender last August to do that. I'm attaching that
code and some example config files to you separately.
Ceki... Could you please put these files in the log4j/contribs/KevinSteppe
folder of the available releases? This seems to be coming up occasionally and
it would
This is probably better for the User list...
1) I created a CompositeRollingFileAppender sometime back which a few
people use. The code is attached along with a couple example config
files.
2) To my knowledge none of the rolling appenders can do this. You are
welcome to modify code...
Kevin
It is my understanding that the DailyRollingFileAppender (regular) is fixed for log4j
1.2. So the Extension version is only needed if you are using log4j 1.1.3
Kevin
Sara Prigge wrote:
Hi Rob-
Attached please find the DailyRollingFileAppenderExt.JAR file. Extract this
into your log4j.jar
number of log files to be kept? That is my
primary reason for using the DailyRollingFileAppenderExt (currently with
log4j 1.1.3).
Thanks!
-Original Message-
From: Kevin Steppe [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 18, 2002 10:53 AM
To: Log4J Users List
Subject
Todd,
Which JDBCAppender are you using (who's the author)? There are two
JDBCAppenders in the contribs section of the log4j distribution. In my biased
assessment, more problems have been reported with the one written by Thomas
Fenner than mine. There will be a official JDBCAppender with
I would recommend:
% Category slog = Category.getInstance(this.class.getName()); %
The important part is that _this_ is referencable in a JSP (it's just a Servlet
class anyway).
The static declaration is nice but not all that necessary. There is only one
object for slog anyway, even if you have
I think Donnie and Simon have expressed most of the pros/cons of logging to a DB.
I'll just add a bit more -- In a geographically distributed environment, a DB table is
often more accessible than a file. Databases have
all sorts of backup and simultaneous access features that may be useful.
I'm jumping in on the middle of a thread so excuse me if I'm missing something.
I'd think the most EJB styled approach would be to put everything in the DB, logs
and configuration. The JDBCAppenders in contribs work well for logging. You'd need a
special configureAndWatch to handle pulling
This all seems very odd to me. First off, according to the cvs for Thomas
Fenner's JDBCAppender (note that there is another one, mine!) contribution the
JDBCLogger does not even have a prepareConnection() method nor does the
appendSQL() method call a prepareConnection() method. So it looks to
A few thoughts:
1) I wouldn't go with the NDC/MDC. The thread information is already passed
along to the appender.
2) The custom appender -- check the thread in the same way PatternLayout does.
3) Wrap the Logger class and check the thread before forwarding the logging
calls. This could help
The result depends on how variable 'sdf' formats the dates involved. Basically
it converts the requested date format into a timing interval for determining
when to do roll overs. I agree however, that it is remarkably unclear and
roundabout in doing this, but if you specify a different format
Hu wrote:
Hi, I am new to log4j. I have some basic questions
about log4j.
1. In what kind of situation the constructor of
appenders that takes parameter will be called? if I
have my own appender that added more params, should I
creat the corresponding constructor?
Since the
Armin,
yes
Kevin
Armin Zeltner wrote:
Hi folks,
which jdk is necessary for log4j.
we're developing a java-realtime-vm for automotive. we support jdk
1.1.8. Enough 4 log4j?
THX armin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
In my opinion Java lacks the best access modifier for OO code -- access for the
class and its descendants but no one else. Protected is close, with package
being a possible choice too. Public access doesn't restrict me and rarely
causes problems even though it's theoretically bad, however not
Nitin,
Always remember to post your configuration when asking this sort of question
-- your problem is clearly a configuration problem. Fenner's appender (the one
I believe you are using) has reasonable extensive documentation, so check that
and modify your config. Alternatively you could
implementation.
Kevin Steppe
--
package org.apache.log4j;
/*
* Copyright (C) The Apache Software Foundation. All rights reserved.
*
* This software is published under the terms of the Apache Software
In your TracerLogger getCategory() method, you have:
cat.addAppender( new AsyncAppender());
That (obviously) creates a new appender for -every- class. Try configuring once and
putting the appender on the root category. Obviously you don't need a different
appender for every
in my code the original LoggingEvent is available in case you want
to customize some code to do extra work.
Kevin Steppe
Joe Sackett wrote:
Ceki,
As the documentation states, The category field
is not serialized for performance reasons.
As expected, the category and fqnOfCategoryClass
fields
Georg,
It is my understanding that all the contributions have to fall under the
Apache License (mine certainly does) so you are free to do almost anything with
it. Personally I strongly encourage you to subclass as that is one of the most
useful features of OO programming -- in fact the
Matthew,
The problem in in your ByteStreamSetup class. You wrap
byteIn around byteOut during construction of the object.
This causes
byteIn to wrap the btye array held by byteOut at
*construction* time -- when the array is null of course. I
moved the byteIn
construction (byteIn = new
My mail system was bad yesterday and this reply didn't appear to go
out... sorry if you're getting it twice:
I'll answer the JDBC questions for my contribution:
1. Logging has historically been made to flat files. Dropping strings
into files is much much faster than doing an insert on a DB.
Thomas et. al,
Thanks for the good news about finding the bug.
I also believe that LogLog stuff is unclean (since it more or less
duplicates the errorHandler functionality) and should be removed as soon as
someone gets around to resolving any remaining difficulties in moving those
log4j-root/contribs/KevinSteppe also has a JDBCAppender which is in my (very
biased) opinion, much easier to use -- plus it allows you to get at all the
parts of a log object and put any part into any column you want.
Kevin
Thomas Tuft Muller wrote:
See JDBCAppender in the
Tim,
I'll do any necessary updating to mine by the end of the week.
Kevin
[EMAIL PROTECTED] wrote:
I haven't checked this yet, but does anyone know if the JDBC appenders will
be updated to support the new %X and MDC so I can specify the column names
I want to write values to without
I've made that suggestion myself. In setFile() of CompositeRollingAppender I
added:
if (!staticLogFileName)
scheduledFilename = fileName = fileName.trim() + sdf.format(now);
I believe that adding the assignment line to the DailyRollingFileAppender will
do the trick though I haven't
Veronica,
Under the current implementation the file is only copied to the new
name (dogtest.log - dogtest.log.2001-07-10) if the application is
running at the time when the change should occur ie midnight. So if you
stop the application before midnight and start it again the next day then
it
DailyRollingFileAppender starts by logging to file.log and
eventually renames that file to file.log.-MM-DD (as
appropriate to the timing) and begins logging to a fresh
version of file.log. Why do this rather than start
logging to file file.log.-MM-DD in the first place so
that all files
Ceki,
what are the chances of changing this to include the date from the start of
logging for the
next release? I'd be happy to make the code changes myself even -- should be trivial.
It will
save a bunch of file renames for the CompositeRollingFileAppender -- or whatever name
is good
I can take a whack at it right away. I'll work up a first crack at it and send
to Mark Ceki for comments and suggestions.
Kevin
[EMAIL PROTECTED] wrote:
- (on vwall2)
email-body was scanned and no virus found
I haven't tried it but it should be. All the configuration
'work' is done by the configuration classes in the Log4J
framework, so as long as the appender has the appropriate
get/set methods and the config file addresses those then it
should work 'out of the box' so to speak. Thank Ceki for a
Ceki,
Did you get my JDBCAppender contribution?
Kevin
Ceki Glc wrote:
Roger,
Thank you for your contribution. However, isn't the JMSLogger just an extension of
JMSAppender?
I find it upsetting that you have chosen to remove the original author's name (me in
this case) when most of the
.
*
* Implements an ArrayList buffer before storing messages to the DB.
* Override getSQL to fit your database schema (or implement spLog msg
on your DB)
* Override executeSQL to modify how DB connection and SQL execution is
made.
*
* @author: Kevin Steppe
*/
public class JDBCAppender extends
56 matches
Mail list logo
