[jira] Updated: (OPENEJB-627) Refactor Logging API to tighten Logger creation

["karan singh malhi (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OPENEJB-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

karan singh malhi updated OPENEJB-627:
--------------------------------------

    Attachment: openejb-627.patch

Refactoring done. This refactoring exercise exposed a few new Loggers (below):
	public static final LogCategory OPENEJB_ADMIN = new LogCategory( OPENEJB.name + ".admin");
        public static final LogCategory OPENEJB_SERVER_REMOTE = new LogCategory( OPENEJB_SERVER.name + ".remote");
	public static final LogCategory HTTPSERVER = new LogCategory( "HttpServer");
	public static final LogCategory SERVICEPOOL = new LogCategory( "ServicePool");
       logger = Logger.getInstance(LogCategory.OPENEJB_SERVER.createChild("service."+getName()),                                                                                                                  
                                                                                                                             "org.apache.openejb.server.util.resources");


> Refactor Logging API to tighten Logger creation
> -----------------------------------------------
>
>                 Key: OPENEJB-627
>                 URL: https://issues.apache.org/jira/browse/OPENEJB-627
>             Project: OpenEJB
>          Issue Type: Improvement
>            Reporter: karan singh malhi
>         Attachments: openejb-627.patch
>
>
> Below is a proposal from Karan Singh:
> -----------------------------------------------------
> The current getInstance method of Logger has the following signature:
> Logger getInstance(String name, String baseName)
> Logger getInstance(String name, Class clazz)
> If one had to obtain a Logger, it is still to easy to do something like
> Logger logger = Logger.getInstance("abc","org.apache.openejb");
> i.e. it is still easy to bypass the LogCategory totally. Over time,
> this might lead to a problem in that we might again end up in a
> situation where we have loggers which are lost in code and are not
> defined in log4j.configuration because nobody knows about their
> existence. I mean, you can still go and add  a Category to LogCategory
> and not update log4j configuration, but this way atleast we have
> tighter control over where to look for all Categories and then update
> log4j if required.
> I am thinking to refactor the Logger and LogCategory as below:
> Logger getInstance(LogCategory category, String baseName)
> Logger getInstance(LogCategory category, Class clazz)
> public final class LogCategory {
>        private String name;
>        public static final LogCategory OPENEJB = new LogCategory("OpenEJB");
>        public static final LogCategory OPENEJB_STARTUP =
>                  new LogCategory (OPENEJB.name + ".startup");
>        ...
>        ...
>        private LogCategory(String name){ this.name = name;}
>        public String getName(){return this.name;}
> }
> What this also gives us is an ability to add methods, for lets say,
> generating LogCategories, given a deploymentId (David blevins idea
> about loggers with deploymentId as a suffix)
> ==============================================================================
> David Blevins enhanced the proposal with a great idea (see below) -- This will be very helpful in creating Loggers with specific moduleId's
> --------------------------------------------------------------------------------------------------
> So I can see some appeal to the idea.  I guess if we used old school
> enums as you propose we could make it work.  We just need some nice
> way to create the "sub categories".  Maybe we could tuck the creation
> of the non static final (the dynamically created) LogCategories away
> as in..
>  // Standard setup part
>  private static final Logger log = Logger.getInstance
> (LogCategory.OPENEJB_DEPLOY, Foo.class);
>  // Now later i need to do something app specific
>  Logger appLog = log.getLogger("mySuperApp");
>  -- - - -- - - - - - -
> Under the covers it might just be something like:
>  return Logger.getInstance(this.logCategory.createChild
> ("mySuperApp", this.packageName);

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.