It's great to have some discussion on this and I'd love to hear from some others
as well.
About contributions: I'll put my JDBCAppender in log4j/contributions later today
unless Ceki has already done it.
I think that perhaps starting up a list of requirements for a JDBCAppender would
make sense at this point. Here's a start:
JDBCAppender feature requirement list:
Can be configured in a log4j.properties file
allows for message buffering
SQL used to generate the log record can be customized easily
Customization can generate the SQL dynamicly based on the event
java.sql.Connection can be generated internally by default or provided
externally
The Appender integrates well and easily with external connection pooling systems
Thomas, I'm sure I've left out some features that are vital to you, so please
add them.
In response to Thomas:
For connections -- I think it's very valuable to have the option not to have the
logger continuously holding a connection. I can easily imagine an environment
where the number of connections is highly restricted and one would like to share
the entire pool among all parts of the system rather than 1 for logging only and
n-1 for the rest.
Again, implementing JDBCConnectionHandler could be a pain if you are using a
byte code only database manager (does others agree or disagree with me on this
one?).
I believe that opening the package to dynamicly changing to different events is
a neccessary feature for any JDBCAppender that would be commited. The same goes
for stored procedures -- maybe not important to you, but vital to others.
Triggers aren't a solution for everyone. In my case lots of different
applications log to the same table(s) and so a trigger for customization won't
work..
For the Logger vs Appender: seems like a potentially useful abstraction, even if
totally useless for me.
"Fenner, Thomas" wrote:
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
