Recommended log method?

Question

question

BillS asked Dec 11, '09 BillS posted Dec 11, '09

Recommended log method?

Just curious as to what the recommended log interfaces is for plugins, ideally so it will go to the execution log along with, and in the format of:

2009-12-11T18:51:18.326: Execution starting: project://my_project/test_cases/new_testcase.fftc
2009-12-11T18:51:18.373: Thread 1: Running
2009-12-11T18:51:18.373: Thread 1: Executable Step /: started

System.out.println works, but it's not exactly ideal. I could use log4j or something else, but I'd really just like to reuse the existing log handles.

Thanks,

-Bill

iTest sdk

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2009-12-12T00:29:56Z

PaulD answered Dec 12, '09 PaulD posted Dec 12, '09

If you're talking about generic logging, the typical approach used in Eclipse plug-ins is to log to System.out, or to create your own console and to log into it. (If you Google Eclipse Console, you'll find lots of examples on how to create a console and use a stream to send text to it.)

We could potentially expose the same console that the iTest execution kernel is using and provide a simple API that ensures that whatever you send appears in the same console. But you might find that a separate console has other benefits as well, as it keeps your stuff nicely separated.

3

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

BillS commented · Dec 12, 2009 at 12:45 AM

Normally for our Eclipse plugins (non-iTest) we use log4j or another logging facade, so we can leverage configurable appenders. This gives us the capability of user-defined log granularity for when we;re debugging issues, eg:

log4j.rootLogger=DEBUG, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout

# Print the date in ISO 8601 format
log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

# Print only messages of level WARN or above in the package com.foo.
log4j.logger.com.foo=WARN

as a simplified example. Then if we run into issues we can have the end user modify the log level to expose everything from warns, to info messages, and so on. Very handy for not needing to be at their desk to get repro data.

So the ideal solution would be to implement a logging facade for the iTest SDK in a similar configurable fashion (or just use a common logging structure), especially with configurable appenders - that way people could set it up to log the plugin log info and core itest log info however it's needed.

In the short term, though, providing access so it goes into the main console would be a good (and easier) place to start - that way things can be in a unified form.. having things separated, at least in our environment, is often a huge pain when users don't always know which files to send to help us debug an issue.

0 ·

PaulD BillS commented · Dec 12, 2009 at 01:28 AM

All sounds reasonable.

0 ·

AdamB BillS commented · Dec 18, 2009 at 04:58 PM

One other option that we have taken with some of our SDK based tools is to create a console as a view to that tool. This console is made read only. It can then show various pieces of information that the tool wants to display for the user.

0 ·

question