You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by "Burnard, Julie (J.A.)" <jb...@ford.com> on 2005/02/28 19:33:18 UTC

Threading and Localization using l7dlog

I just purchased a copy of the book entitled "The Complete log4j
Manual".  I was disappointed to find that it doesn't mention anything
about localized messages using the l7dlog methods. I guess the title is
somewhat misleading.

Maybe someone out there can give me some guidance.

I'm in the process of providing a log4j wrapper class that implements
the 'log' type statements from the jdk 1.4 java.util.logging.Logger
class.  Note, our organization is not yet utilizing jdk 1.4, so we've
implemented a jdk1.4 like logging interface in our frameworks that we
can map to multiple logging frameworks.  Hopefully this will allow us to
more easily move to jdk1.4 logging in the future if so desired.  One of
the mapper implementations we're supplying is a Log4JMapper.  In the
Log4JMapper class, I need to utilize the l7dlog methods of log4j when a
resource bundle has been associated with the Logger class instance, as
well as when a logrb() method is called.  Everything I read says that
log4j is thread-safe.  But I can't find much information around what
this means when using the l7dlog methods.

Here is my concern:

Typically each class developed in our environment will contain a static
instance of a mapper class that is instantiated with it's fully
qualified classname.  If using the Log4JMapper, then the class will
contain a static instance of a Log4JMapper class.  Note that this static
instance could have been created with an associated ResourceBundle that
all 'log' type methods should use when trying to log a message for this
class.  The instance of log4JMapper also contains a reference to it's
corresponding org.apache.log4j.Logger instance.  If a ResourceBundle was
used to initialize the Log4JMapper object, then
logger.setResourceBundle(resourceBundle) is used to set the
ResourceBundle on the contained org.apache.log4j.Logger object.  All
this is fine, and when any 'log' type method is called, then the
Log4JMapper class uses the proper l7dlog method to log a localized
message.

However, if a 'logrb' method is called with a ResourceBundle other than
the one used at creation time, the Log4JMapper needs to temporarily
switch the ResourceBundle associated with it's static
org.apache.log4j.Logger object before calling the l7dlog method.  After
calling l7dlog method, the Log4JMapper will switch the ResourceBundle
associated with it's static org.apache.log4j.Logger object back to the
ResourceBundle used at creation time.  I'm concerned this poses a
threading issue if another instance of the the class calls a 'log'
method during the time that the ResourceBundle has been temporarily
swapped.  Can you tell me if there are any issues in this scenerio?

Note - I can send along the Log4JMapper class if it would help to
understand my concern.  Here is one of the logrb methods for reference:

/**
* Log a message contained in the specified ResourceBundle using the key
* provided. Note, the resourceBundleName specified at initialization
* of the logger has no effect on this method. 
* 
* Log4j uses what is defined in logging API terms as 'msg' as the
* 'key' to retrieve the value from the resource bundle. Therefore no
* manipulation of the msg string will take place (such as appending
* the method name etc).
* 
* @param level
*     Level to use for logging
* @param sourceClass
*     The class name is ignored. See the note above.
* @param sourceMethod
*     The method name is ignored. See the note above.
* @param bundleName
*     The name of the ResourceBundle to use. 
* @param key
*     key used to look up a message in the ResourceBundle specified
*     by bundleName
* 
* @see ILogger#logrb(Level, String, String, String, String)
*/
public void logrb(
Level level,
String sourceClass,
String sourceMethod,
String bundleName,
String key) {

    boolean switchBundle = false;

    if (!bundleName.equals(this.resourceBundleName)) {
        ResourceBundle bundle = ResourceBundle.getBundle(bundleName);
        this.logger.setResourceBundle(bundle);
        switchBundle = true;
    }

    this.logger.l7dlog(getLog4jLevel(level), key, null);

    // If a resourceBundle has been defined for this logger, switch the 
    // Log4J logger back to the ResourceBundle associated with this
logger. 
    if (this.resourceBundle != null && switchBundle) {
        this.logger.setResourceBundle(this.resourceBundle);
    }
}

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: Threading and Localization using l7dlog

Posted by Curt Arnold <ca...@apache.org>.
On Feb 28, 2005, at 12:33 PM, Burnard, Julie (J.A.) wrote:

> I just purchased a copy of the book entitled "The Complete log4j
> Manual".  I was disappointed to find that it doesn't mention anything
> about localized messages using the l7dlog methods. I guess the title is
> somewhat misleading.
>
> Maybe someone out there can give me some guidance.
>

My personal opinion is that resource bundle approaches to logging are 
usually not the best approach for localization of logging.  I think a 
localizing layout is a more practical approach for most applications.  
Sorry there isn't one in log4j yet.

I joined in a discussion on commons-logging starting with 
http://mail-archives.apache.org/eyebrowse/ReadMsg?listId=15&msgNo=62351 
which involves several other interweaving topics.


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: Threading and Localization using l7dlog

Posted by James Stauffer <st...@gmail.com>.
Burnard, Julie (J.A.) <jb...@ford.com> wrote:
> I'm in the process of providing a log4j wrapper class that implements
> the 'log' type statements from the jdk 1.4 java.util.logging.Logger
> class.  Note, our organization is not yet utilizing jdk 1.4, so we've
> implemented a jdk1.4 like logging interface in our frameworks that we
> can map to multiple logging frameworks.  Hopefully this will allow us to
> more easily move to jdk1.4 logging in the future if so desired.
I like log4j so I may be a bit biased but what would you gain by
switching from log4j to java 1.4 logging.  Log4j has more features. 
Basically, is there any gain by writing your own mapper instead of
just using log4j directly?

-- 
James Stauffer
http://www.geocities.com/stauffer_james/

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: Threading and Localization using l7dlog

Posted by James Stauffer <st...@gmail.com>.
Burnard, Julie (J.A.) <jb...@ford.com> wrote:
> Typically each class developed in our environment will contain a static
> instance of a mapper class that is instantiated with it's fully
> qualified classname.  If using the Log4JMapper, then the class will
> contain a static instance of a Log4JMapper class.  Note that this static
> instance could have been created with an associated ResourceBundle that
> all 'log' type methods should use when trying to log a message for this
> class.  The instance of log4JMapper also contains a reference to it's
> corresponding org.apache.log4j.Logger instance.  If a ResourceBundle was
> used to initialize the Log4JMapper object, then
> logger.setResourceBundle(resourceBundle) is used to set the
> ResourceBundle on the contained org.apache.log4j.Logger object.  All
> this is fine, and when any 'log' type method is called, then the
> Log4JMapper class uses the proper l7dlog method to log a localized
> message.
You probably want a separate logger per Resource Bundle.  In order to
achieve that you could take a part of the Resource Bundle name and add
it to the logger name so that it will be separate from other loggers
by the same name that use a different ResourceBundle.

-- 
James Stauffer
http://www.geocities.com/stauffer_james/

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: Threading and Localization using l7dlog

Posted by James Stauffer <st...@gmail.com>.
Burnard, Julie (J.A.) <jb...@ford.com> wrote:
> I'm in the process of providing a log4j wrapper class that implements
> the 'log' type statements from the jdk 1.4 java.util.logging.Logger
> class.  Note, our organization is not yet utilizing jdk 1.4, so we've
> implemented a jdk1.4 like logging interface in our frameworks that we
> can map to multiple logging frameworks.  Hopefully this will allow us to
> more easily move to jdk1.4 logging in the future if so desired.
You may want to check out Apache commons logging.  "The Logging
package is an ultra-thin bridge between different logging libraries."

http://jakarta.apache.org/commons/logging/

-- 
James Stauffer
http://www.geocities.com/stauffer_james/

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org