Niclas Hedhman wrote:
> On Friday 24 May 2002 23:37, Kevin Steppe wrote:
>
>> Niclas Hedhman wrote:
>>
>>> SQL is by default an evil thing and should not be exposed to users, nor
>>> programmers.
>>
>> That is rather opinionated, just like the following:
>> SQL is by default an incredibly elegant, simple, and powerful
>> programming language -- in some ways more elegant and powerful than
>> Java. All programmers would benefit from learning SQL.
>
>
> When I say "evil" I mean "current specification is not strict enough and
> allows for the implementation vendors to extend it in all kinds of
> incompatible directions", hence making "pluggability" a paper-tiger.
The assanine attitude of the vendors towards the standards is indeed
evil. I agree with you whole heartedly on that one. In the abstract
however, I think SQL is wonderful.
>
>
>>> I suggest that the SQL is completely hidden from Log4J, so that each
>>> JDBC-using appender has a method, or a client class, that takes care of
>>> the retrieval of the exact same information as what can be stored, plus
>>> some basic search methods (not SQL based) and optionally(!) have an
>>> exposure of SQL statement executions.
>>
>> Under the current design appenders in log4j only store LoggingEvents not
>> retrieve them, so it would be rather odd for the JDBCAppender to have
>> search methods. Log reading is delegated to Chainsaw/user/etc. In fact
>> the log formats are primarily the domain of the Layout classes, not the
>> appenders. I believe that this was a very wise design choice. I
>> suspect it's useful for appenders to expose information about their
>> output formating/etc for the benefit of a reader, but I'll let Chainsaw
>> folks take authority on that one.
>
>
> Badly formulated on my part.
> The MySQLAppender, should be accompanied by a MySQLRetriever, that is
> pluggable into Chainsaw and other viewers. This is not violating the Log4J
> design philosophy, because the SocketAppenders has the corresponding classes
> "for the other end", which in your argument should not be the case.
>
>
>> The programmer writes: log.debug("a debug message") [no SQL]
>> The deployment person puts in the config: sql=insert into logTable
>> (logMessage) values ('%m') [only enough to pick the right output]
>> This supports all DBs, and the SQL is completely hidden from log4j and
>> it's user.
>
>
> If the deployer is allowed to send the log record into any database in any
> format, you yell "Bravo", and I whisper "too bad". I will bet that most
> deployers only require that he/she specifies the Host+port+DB and the name of
> the Table (plus user/pass of course).
>
> However, I am arguing that a rather fixed format is established, or ChainSaw
> and others will never manage to pick up the info, and you would discourage
> small 3rd party tools to analyze the data.
This is why I proposed the 2 tier implementation.
>
> So, to re-phrase;
> Instead of talking about JDBC appenders, let met introduce the concept of
> Retrievers, which are implemented as a companion to Appenders.
> The rationale is that exactly the same is true for non-JDBC appenders, such as
> for XML and even text files.
> If the Retriever interface is established, then it is up to the Appender
> writer to provide, or risking that people won't use it due to inaccessability
> of the output.
>
> As for JDBCAppender, I think it will evolve a little bit, so that the
> Retriever interface would/can be supported, and free format Insert statements
> are probably not reasonable.
I really like the Retrievers idea! The Retrievers pattern should be
able to read the configuration files so as to properly set itself up. I
still feel that the Layout pattern is more important than the actual
appender in reading log information, however.
What are other people's opinions on the Retrievers idea?
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
