[Cosmo-dev] Output going in to log4j

[Mikeal Rogers]

On Jun 27, 2006, at 3:37 PM, Brian Moseley wrote:

> (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.

I'll log that request as soon as I have some time to investigate and  
watch all my current tests run and dig through the output.

Keep in mind that eventually this test system will be streamlined and  
run automatically after each checkin, and when a failure happens  
we'll be able to send you all the data we have on the failure. If  
there is any output that would also help you, even if it isn't  
directly needed by us, it would be good to have it in as well.

>
>> 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.

I hate that word... 'proprietary'... grr.

>
> 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.

Even if we couldn't get it in to log4j, we could write another app  
that just watched the file, so long as it's flushing it's write  
buffer after every line.

>
>> 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.

Ok, I'll log the initial request tomorrow for the upgrade and log  
level tweaks. When I have time to look at it in depth I'll log  
another request for the specific output we would like.

> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev