openejb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "karan singh malhi (JIRA)" <j...@apache.org>
Subject [jira] Created: (OPENEJB-627) Refactor Logging API to tighten Logger creation
Date Wed, 08 Aug 2007 03:59:59 GMT
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


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.


Mime
View raw message