I've done something similar, except I use an ArrayList to keep an ordered
list of insert values to fill in the ? for the prepared statement. I store
the actual SQL string in the database as well, and pull it out at
initialization. I may begin storing all the init properties in the
database, and have a row for each appender. It seems to me that a JDBC
appender should also have its init properties in the database as well, just
so you have a consistent interface (in this case oracle/mysql client)
instead of having to switch between database and files. I haven't thought
about it much, so I may change my mind on that.
Also, I create a separate thread, and share the event ArrayList between the
main thread and the new thread. The new thread does the actual insertion
of the statements. I have a few more ideas that I'd like for a JDBC
Appender, but I just wanted the message for now. The
getClassName/MethodName, etc don't work in the JDBCAppender, so I'll
probably modify it to work as well.
I like the idea of the comma separated list as well. Right now my order is
not so flexible.
Right now I have three classes:
JDBCAppender (hooks into the log4j framework)
LoggingThread (thread that checks the buffer/buffercount)
JDBCLogger (the actual JDBC logging class that encapsulates the
database-specific stuff)
JDBCAppender instantiates JDBCLogger and passes on the properties.
JDBCAppender instantiates LoggingThread and starts it, passing the
JDBCLogger class into the LoggingThread.
St
|---------+---------------------------->
| | Kevin Steppe |
| | <kevsteppe@yahoo.|
| | com> |
| | |
| | 06/17/2002 05:58 |
| | PM |
| | Please respond to|
| | "Log4J Users |
| | List" |
| | |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------|
|
|
| To: Log4J Users List <[EMAIL PROTECTED]>
|
| cc:
|
| Subject: RE: Log4j JDBCAppender
|
>--------------------------------------------------------------------------------------------------------------|
Andrew,
If you're willing, I'd love to see the code. I like
your idea of the comma-separated keys and would like
to see how you've implemented it.
If setObject will work for all types then that will
be the way to go. For my own enlightenment, why would
a company prevent developers from using a stored proc.
for repeatedly executed sql?
Kevin
--- "Tumpach, Andrew J" <[EMAIL PROTECTED]> wrote:
> I've extended the JDBCAppender to do
> PreparedStatement work. Here's a synopsis: pass in
> a Hashtable as the message, with multiple database
> columns' values in it. A new property in the log4j
> property file contains comma-separated keys (in the
> order used in the SQL statement) used to pull values
> out of the Hashtable. Re #1 below,
> PreparedStatement.setObject() works just fine so
> far. Re #2, escaping is not an issue with Prep.
> Stmts. Re #5, some shops don't let developers do
> stored procs. My main problem right now is Ceki's
> declaration of the uncertain future of JDBCAppender.
> :)
>
> Andrew
>
> -----Original Message-----
> From: Kevin Steppe [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 06, 2002 11:28 AM
> To: Log4J Users List
> Subject: Re: Log4j JDBCAppender
>
>
> The double quote should fix #2. Any time you are
> putting a string into
> a varchar type field you should use either single or
> double quotes.
> Without quotes you'll have all sorts of errors. As
> for performance
> successful statements will always go faster than
> failed statements :)
>
> The preparedStatement option seems nice in theory
> but I believe doesn't
> merit the work:
>
> 1) The configuration would need to be more
> complicated to properly
> handle the variety of types/values/etc you might
> want to set.
> 2) Escaping is still a problem, b/c the appender has
> to handle any
> number of quotes in a general fashion (unlike your
> example where you
> know exactly how many and where the quotes are)
> 3) The performance value of preparedStatements is
> debate-able.
> 4) Batch inserts make far more difference and will
> be included very soon
> (it's being tested)
> 5) stored procs will work the current appender which
> is the same or
> better than preparedStatements anyway
>
> Stored Procedure example (works with MS-SQL, not
> tested on Oracle)
>
> sql= myLoggingSproc "%c", "%t", "%p"
>
> Kevin
>
>
>
> Jon Wilmoth wrote:
>
> >The double quote around the thread worked to fix
> the multiple single quote
> >problem.
> >
> >That sounds like a very good approach as it handles
> the previous problem and
> >should also handle the next problem (see #2). It
> should also improve the
> >also performance correct?
> >
> >#2 Unfortunately, the next problem is the weblogic
> thread string
> >(ExecuteThread: '11' for queue: 'default') also
> contains colons, which
> >oracle 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 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
> >>escaping. As far as I can tell the JDBC version
> in JDK1.3.1 does not
> >>have a generic escape call. If I'm wrong, someone
> please tell me so I
> >>can get that into the JDBCAppender.
> >>
> >
> >Kevin,
> >
> >Ideally the appender would support the optional use
> of PreparedStatement
> >objects, rather than building SQL strings
> dynamically. With a
> >PreparedStatement there is no need to escape any
> text values. For example:
> >
> >PreparedStatement st =
> conn.prepareStatement("insert into logtable
> >(threads) values (?)");
> >try
> >{
> > st.setString(1, "I can put single quotes ' and
> double quotes \" in
> >this text");
> > st.executeUpdate();
> >}
> >finally
> >{
> > st.close();
> >}
> >
> >I believe this would take some reworking of the
> current JDBCAppender,
> >however, due to the fact that simple text
> replacements cannot be used.
> > Instead there would have to be some way to
> associate a the integer
> >parameter index with a piece of data (%t or
> whatever).
> >
> >BTW, I don't actually use the JDBCAppender myself
> -- that's my
> >view-from-the-outside.
> >
> >Ben
> >
> >
> >
> >--
> >To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> >--
> >To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> >
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
>
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]
>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]
>
--
NOTICE: This e-mail message and all attachments transmitted with it may
contain legally privileged and confidential information intended solely
for the use of the addressee. If the reader of this message is not the
intended recipient, you are hereby notified that any reading,
dissemination, distribution, copying, or other use of this message or
its attachments, hyperlinks, or any other files of any kind is strictly
prohibited. If you have received this message in error, please notify
the sender immediately by telephone (865-218-2000) or by a reply to this
electronic mail message and delete this message and all copies and
backups thereof.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
