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. Of course
analyzing messages in a DB is much more flexible.
a. testing/reliability -- I have personally been contacted by several
people using my JDBCAppender in commercial/professional settings. This
is probably several orders of magnitude less usage than the main classes
of Log4J. On the good side, no one has ever reported a bug with my
JDBCAppender so I'd call it very reliable. It's also fairly simple with
makes reliablity more certain.
b. performance -- hmm... I've never done any specific speed tests -- your
performance will probably be dominated by the speed of insertion on the
database itself + network overhead + ... My JDBCAppender does not handle
connection caching or pooling -- this is intentional because different
environments have different API's and mechanisms for handling this.
Override the executeSQL(String sql) method to provide your own connection
handling (this is what I do with a home built pooling mechanism).
I haven't used JMS so I can't comment on that.
If I remember correctly, bulk inserts are not yet part of the SQL
standard and are handled very differently on different systems (ex.
MS-SQL requires a non-SQL based app to be run). So I didn't try to build
seperate methods for different systems. You could override flushBuffer()
and make it call the appropriate bulk load stuff for your DB, or lock the
table and do the inserts through executeSQL(String sql). If you have -a
lot- of message that you want to buffer this could be a big performance
boost.
c. discussion/docs -- JavaDoc is your friend. The archives should have
most of my comments about JDBCAppenders. I'd be happy to discuss or
document whatever you need to know.
d. ObjectRendering -- Very cool idea, I'm glad I was thinking about that
10 months ago. My getSQL(LoggingEvent event) which generates the needed
SQL statement, takes a generic event rather than a string or some such.
This design was intentional so you can override it to query the type of
event and Render it properly.... Personally, I keep my event objects the
same and provide a pattern layout which is smart enough to put the
interesting fields into the right columns (this is a very flexible method
since you can extend the pattern layout to handle special log messages).
I hope that helps, if you have more questions write,
Kevin
ps. If anyone is hiring in the Bay Area....
Noah Davis wrote:
> Hi, I'm a complete newbie to Log4J, Apache projects,
> and somewhat to J2EE, so I apologize in advance for my
> naivete - if these questions have been previously
> answered/covered somewhere else and this isn't the
> right forum, please just point me in that direction.
> Thanks in advance. And sorry for the spew of questions
> . .
>
> I've looked through a lot of the documentation, and
> some of the code, and here's some questions:
>
> 1. Using a JDBC adapter
>
> I would have thought that this would be a primary
> usage of Log4J, but there's not one associated with
> the official release, just from contributions. Is
> there a reason for this? I also have several questions
> regarding the JDBC adapters available as
> contributions:
>
> a. How comparatively reliable/tested are the
> contributions in relation to the official release?
>
> b. How performant are the JDBC adapters available?
> And, is there a way to speed/degrade performance by
> using:
>
> - JMS in addition to JDBC
> - Build a system whereby numerous log requests are
> queued up such that only a single database call is
> required for multiple inserts
>
> c. Are there discussions/documentation about the JDBC
> adapters available?
>
> d. Are the JDBC adapters compatible with
> ObjectRenderers? Ie, can I store different kinds of
> objects in different tables even . . (I'm pushing it
> here, I reckon. Am I asking Log4J to do something it's
> just not built to do?)
>
> 2. Using Log4J in Weblogic and in a cluster
>
> I know that Log4J can be configured at runtime, but
> how would you go about configuring it across a
> cluster, ie such that making a change to a
> configuration file at runtime changes the behavior of
> log4j across the cluster? Additionally, what is the
> recommended approach for how to package Log4J (in J2EE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
