Hello Kevin,
the source-files will be placed here soon :
http://support.klopotek.de/log4j/jdbc/JDBCLog.jar
To your questions, minuses, suggestions and stuff :
* The JDBCConnectionHandler should be implemented by anyone who wants
to handle the connection by themself.
The JDBCAppender only wants to have any connection from the
JDBCConnectionHandler to append messages into.
For the most common cases it is just one connection necessary.
The connection will definitly only used for appending purposes !
Nothing else will happens, no closes, etc...
Everything else has to be done by JDBCConnectionHandler itself !
If you wont implement a JDBCConnectionHandler, the connection is
handled by JDBCAppender's Default-JDBCConnectionHandler, using the
database-options.
This self-created connection will be closed.
* Logging dynamically into different columns and tables, depending by
the message-event, the priority and the layout is certainly a point for
enhancing this package,
but it is not fundamental necessary feature for us.
To call stored procedures is maybe a method for customize the
message-handling, but we dont want to do that.
The usage of the JDBCAppender and the Log4J-package should offer
enough customization around the message-handling, so we control our messages
inside.
But feel free to define triggers for further customization...
* The JDBCAppender and the JDBCLogger are separated, because the
JDBCLogger encapsulates the whole behaviour around the JDBC-logging and
could be used anywhere else.
The JDBCAppender is a appender-extension to combine the
Log4J-package with JDBC-logging.
* Yes, we will throw more specific exceptions. Sorry about that...
:-) Thomas Fenner ([EMAIL PROTECTED])
-----Ursprüngliche Nachricht-----
Von: Kevin Steppe [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 14. Februar 2001 00:11
An: LOG4J Users Mailing List
Betreff: Re: JDBC Appender
Oliver,
I'd be interested in seeing the code that implements this -- I'm
still a little vague on how some of the interfaces interact.
I'll first make some comments on your JDBCAppender and at the end
I'll talk a little about how I put mine together.
Question:
What happens to the connection the JDBCConnectionHandler passes? Is
it held, closed, ...?
Plusses:
I really like that you can read a table definition and build an
appropriate SQL statement.
I like the column definition stuff.
Minuses:
It seems rather more complicated than necessary (compare with my
JDBCAppender) though I could be missing some vital functionality that I
don't use.
I don't see any mechanism for making use of a connection pool.
Splitting up the LoggingEvent message into different columns isn't
possible without source code -- you'd have to override
JDBCAppender.append(LoggingEvent event) which is sufficiently central that
you'll need to read the source in order to not lose functionality.
Suggestions:
Would it make sense to roll JDBCLogger into the Appender?
Change some of the Exception throws to SQLException throws where
appropriate.
Have an getSQL(LoggingEvent event) call that can be overriden to
mutate the SQL statement based on the event.*
Add putConnection(java.sql.Connection con) to JDBCConnectionHandler
to allow it to handle the connection after use.
Have JDBCConnectionHandler execute the SQL -- replace the
getConnection methods with executeSQL(String sql)
Remove JDBCConnectionHandler entirely, and let subclasses of
JDBCLogger/JDBCAppender handle proper connection handling and statement
execution.
My stuff:
I assumed from the beginning that everyone will have a different
schema for log events in their database and in particular that information
about the event may going in different columns or tables (one column for the
message, one for the thread name, one for stack trace, etc.) Additionally
many developers will have different ways of accessing the database --
through JDBC wrappers, application servers, EJBs -- and that source for the
access classes may not be availible (making adding interface implementations
impossible or requiring an annoying little wrapper). My solution to this was
to assume that the appender will be subclassed to provide those parts of the
implementation. Then the JDBCAppender tries to make it's subclasses very
easy to write (only overriding the two environment specific methods). I also
wanted to provide a default implementation that would work "out of the box",
so I decided on calling a stored procedure which can be written by the
deployer. I think that this method is a lot simpler than yours, and a bit
more flexible in some areas. It's also missing a lot of good functionality
that you have, and the ability to figure out a table.
* about events -- in log4j 1.1 the Appender and Layout will have
access to the original object sent to the Category. An override of getSQL
will be able to make good use of this feature. For example I plan to
generate SQL based on the class of the object sent -- regular log events go
into LogTable, audit events go into LogTable + AuditOld + AuditNew, etc. --
so it's important to allow the sql to be generated dynamically.
Kevin
"Komoll, Oliver" wrote:
Hi,we have also build an JDBC-Appender for our project (its
not the final release - but i think its good for a discussion)You will find
the javadoc under <http://support.klopotek.de/log4j/jdbc/index.html>Anybody
is invited to discuss about the interface. Also, if its helpfull, it can be
integrated to log4jOliver Oliver KomollKlopotek & Partner GmbHE-Commerce
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
