[Cosmo-dev] Output going in to log4j

[Brian Moseley]

(removing scooby-dev from recipients, since the list memberships are
pretty much the same)

On 6/28/06, Mikeal Rogers <mikeal at osafoundation.org> wrote:
> In QA we're in the middle of writing a nice little client application
> that connects to a log4j telnet appender that we can query for
> verification that certain events happen in cosmo and scooby within
> our emulated client test cases.

neat!

> One issue we are running in to is that in many cases there is very
> little or no output. One example is that when most successful
> requests are fulfilled there is no output suggesting "x was created"
> or "query for x return results y". There are many other places where
> this kind of output would be great, at this point it seems that very
> little successful operations in cosmo and scooby give output, unless
> we are missing an unknown filter or something.

speaking for cosmo, you're right. trace level output is definitely
spotty. if you can more precisely define exactly what you want to see,
we can add it where it doesn't already exist.

> Another suggestion from John was to see if there was a way for us to
> output all the SQL queries from derby.

unfortunately, derby use a proprietary logging mechanism, so it might
be hard for you to tie it into your tool.

it is possible to have derby log all queries by adding a specific
option to JAVA_OPTS when starting the server. i forget the specific
one now, but i did this on at least one of my dev machines before i
left for vacation, so i'll figure out the details and add them to the
faq. note that this output goes to the derby log file.

> I'd like to leave this open to the list, but my initial suggestion is
> that we create a few new filters that will be used for log4j output
> so that the current log files don't bloat due to the load of all this
> new output and we can just pick these up in our telnet appender. And
> I'd like to target the low hanging fruit for the next release, I
> imagine there are 10 or so places that if we added some output we
> would cover the vast majority of our need for the upcoming releases.

i don't think we need any filters. we can simply turn off debug level
logging for the majority of our source packages for the production
configuration, and you can tweak the config to turn on tracing for
testing.

also of interest - i believe the latest version of commons-logging
supports the TRACE log level, which is more appropriate for the info
you're asking for. so maybe we should upgrade commons-logging in 0.5,
add the trace output you want, and change existing trace output to use
that new log level.

i suggest opening an enhancement request for cosmo and listing
specifically what tracing you want to see.