BillS avatar image
BillS asked BillS posted

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.





10 |950

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

1 Answer

PaulD avatar image
PaulD answered PaulD posted

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.

10 |950

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

BillS avatar image BillS commented ·

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

# 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

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 Likes 0 ·
PaulD avatar image PaulD BillS commented ·

All sounds reasonable.

0 Likes 0 ·
AdamB avatar image AdamB BillS commented ·

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 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

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