You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by "karan singh malhi (JIRA)" <ji...@apache.org> on 2007/08/08 05:59:59 UTC
[jira] Created: (OPENEJB-627) Refactor Logging API to tighten
Logger creation
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.
[jira] Closed: (OPENEJB-627) Refactor Logging API to tighten Logger
creation
Posted by "David Blevins (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENEJB-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Blevins closed OPENEJB-627.
---------------------------------
Resolution: Fixed
Fix Version/s: 3.0
Assignee: karan singh malhi
All committed!
$ svn ci
Sending container/openejb-core/src/main/java/org/apache/openejb/OpenEJB.java
Sending container/openejb-core/src/main/java/org/apache/openejb/util/LogCategory.java
Sending container/openejb-core/src/main/java/org/apache/openejb/util/Logger.java
Sending server/openejb-ejbd/src/main/java/org/apache/openejb/server/ejbd/AuthRequestHandler.java
Sending server/openejb-ejbd/src/main/java/org/apache/openejb/server/ejbd/EjbDaemon.java
Sending server/openejb-ejbd/src/main/java/org/apache/openejb/server/ejbd/ServerSideResolver.java
Sending server/openejb-http/src/main/java/org/apache/openejb/server/httpd/HttpServer.java
Sending server/openejb-server/src/main/java/org/apache/openejb/server/ServiceLogger.java
Sending server/openejb-server/src/main/java/org/apache/openejb/server/ServiceManager.java
Sending server/openejb-server/src/main/java/org/apache/openejb/server/ServicePool.java
Sending server/openejb-telnet/src/main/java/org/apache/openejb/server/telnet/TextConsole.java
Sending server/openejb-webadmin/src/main/java/org/apache/openejb/webadmin/httpd/HttpServer.java
Transmitting file data ............
Committed revision 564085.
> 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
> Assignee: karan singh malhi
> Fix For: 3.0
>
> 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.
[jira] Updated: (OPENEJB-627) Refactor Logging API to tighten
Logger creation
Posted by "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.