Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hudson-dev] [Hudson-Dev] Re: Questions and ideas for JSR330 plugins
Ah, I missed that part of your suggestion. I like the suggestion, It makes it easy to provide an UI to search and find the logger and create the filter. Let us do it :-) 

- Winston

On 2/7/12 4:20 PM, Jason Dillon wrote:

On Feb 7, 2012, at 4:02 PM, Winston Prakash wrote:

Let us say the good practice is for the plugin to create their own Logger.

I suggest that best practice is more along the lines of out the slf4j api is used (with class names of components doing the logging):

http://slf4j.org/manual.html



On the other hand we need to make it easier for the user to filter the logs corresponding to a logger and view the result in the Hudson Dashboard [1]. The hardest part is to find the correct logger.

I'm not sure if you have been following the comments I've been making on this or not...

My suggestion is that if you want to implement a feature in Hudson to allow users to easily select what level loggers are configure with, would be to implement a component to allow plugins to describe their logger categories and map them relevant details.  Then write a management link page to show the details from the description components and facilitate users changing them.

I highly recommend this route vs. suggesting that plugins use a single logger or by forcing plugins (and classes used by plugins) to follow some naming scheme (which 3rd-party tooling is likely to not support anyways).

public interface LoggingDescriptor
{
     String getName();
     String getDefaultLevel();
     String getDescription();
     String getPluginId();
}

Plugins can implement as many of these as they want:

@Named
@Singleton
public class MyPluginInternalLoggingDescriptor
     implements LoggingDescriptor
{
     public String getName() { return "some.package.myplugin.internal"; }
     public String getDefaultLevel() { return "INFO"; }
     public String getDescription() { return "Internal logging for MyPlugin"; }
     public String getPluginId() { return "myplugin"; }
}

And continue to use loggers as they would normally using the class-name of the component (or current class for sub-class support).

Then in the management thingy, inject:

List<LoggingDescriptor>  loggingDescriptors;

Sort by name, and then render the table with options to configure the logging.



To make it easier to find the logger, does it make sense to introduce a convention. By that I mean encourage the plugin authors to use a logger name such as "org.hudsonci.<plugin-name>"
For example

private String loggerName = "org.hudsonci.deploy"
protected final Logger log = LoggerFactory.getLogger(loggerName);

Note, I used LoggerFactory.getLogger(String name) rather than LoggerFactory.getLogger(Class clazz)

Is this approach has any disadvantage?

3rd-party libraries already using logging are almost not going to facilitate following this pattern.  So event by using a convention you still don't fully solve the problem.

If the problem you are trying to solve is to facilitate human readable/easily comprehendible logging mapping to plugins, then I think they only way to do this 100% is to implement something like a LoggingDescriptor&  related UI to manage them.

  * * *

I feel like I could have already written this in the time its taken for me to respond to all of the emails over it :-P

--jason

Back to the top