• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Log4j Wrapper

 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
We are creating log4j wrapper for our application as follows.Will this create any threading issue..
public class LoggingUtil {
static Logger logger = Logger.getLogger(LoggingUtil.class);
public static void debug(Class<?> classNm,Object message)
{
if(logger.isDebugEnabled()){
logger.log(classNm.getName(), Level.DEBUG, message,null);}
}

}

Thanks and Regards
A.Raj
 
Ranch Hand
Posts: 608
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's thread safe, because it has no state. Any class that has no state would be fundamentally thread safe.

On a side note, why would you want to create such a wrapper, it does not offer any benefit over the usual logging API!
 
Ranch Hand
Posts: 63
Spring Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Arockia
Why do you think it will create any threding issue?
 
Arockia Raj
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Saifuddin Merchant wrote:It's thread safe, because it has no state. Any class that has no state would be fundamentally thread safe.

On a side note, why would you want to create such a wrapper, it does not offer any benefit over the usual logging API!




Thanks for the reply...The reason for this wrapper class is,we dont want to have 3rd libraray jars(com.apache.log4j) inside all over application codes and prefer to restrict to one wrapper class..so that in future if we decide to change log4j with any async implementation then the impact is only for the wrapper calss
 
Arockia Raj
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Niraj Jha wrote:@Arockia
Why do you think it will create any threding issue?


@Niraj :Thanks for the reply,the reason is this class is having static instance Logger variable..hence need to sure it will be thread safe..
 
Bartender
Posts: 3323
86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

the reason is this class is having static instance Logger variable..hence need to sure it will be thread safe..


The Log4J docs say "Calling the getLogger method with the same name will always return a reference to the exact same logger object." so it doesn't matter if you have a static reference to the logger or get a new reference each time one of your wrapper methods are called, for a given logger name you will always use the same logger object.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic