Hello Ceki,
i have just updated the file JDBCLog.jar by replacing the string
"Copyright (c) 2000 Klopotek & Partner. All rights reserved."
with
"Copyright (C) The Apache Software Foundation. All rights reserved."
.
:-) Thomas ([EMAIL PROTECTED])
-----Ursprüngliche Nachricht-----
Von: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 14. Februar 2001 20:09
An: LOG4J Users Mailing List
Betreff: Re: JDBCAppender
Thomas,
Thanks for creating JDBCLog.jar. If you would like me to add this to the
contribs/ directory, then you must change the Kloptek & Partner AG
copyright notice to Apache Software Foundation copyright. According to ASF
rules, non-APLed code cannot be added to the CVS repository on Apache.
Regards, Ceki
At 17:09 14.02.2001 +0100, you 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]
----
Ceki Gülcü e-mail: [EMAIL PROTECTED] (preferred)
av. de Rumine 5 [EMAIL PROTECTED]
CH-1005 Lausanne
Switzerland Tel: ++41 21 351 23 15
---------------------------------------------------------------------
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]
