• 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

this and static don't mix

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i was asked to retrofit a legacy codebase to use log4j vs. jakarta-commons logging.
there are about two-dozen classes that inherit from one base class, yet the logger gets instantiated in one method, then passed around from method to method within the same class.
this is the case for each of the two-dozen subclasses in my charge.
i thought it would be appropriate to instantiate the logger in the base class, using a protected field, then let each subclass inherit that functionality.
the snag i've hit is that some of the subclasses are intended to be singletons and use only static methods. not a problem (maybe?) except that i'm passing "this.getClass()" into log4j in the base class instantiation.
probably many of you are already saying, "you can't use 'this' in a static method" -- which is the reason i'm writing this post...
what is the best way to tackle this dilemma? i'm facing 29 compile errors about not being able to use 'this' in a static context, but i'm not so experienced in java that i know what to do?
can i just eliminate the static keyword from the method(s) in question?
should i change my default name from this.getClass() to Class.getName()?
i'm trying to maximize the realized benefits from an o-o implementation but i'm stuck behind my ignorance.
looking forward to your help...
richard
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's more common, and would solve your problem, to have each class have its own logger. The idiom I follow in logged classes:
 
Charles Richardson
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hm... I have to admit that I'm a bit surprised by your answer. Not disagreeing with you, just surprised; here's what I'm thinking:
Just as today I'm charged with upgrading the logger from jakarta-commons to log4j, what if sometime soon i'm charged with upgrading log4j with some other logging mechanism?
In that case, it seems to me that I'd have to repeat my effort of getting into each class and retrofitting the log4j stuff. Not only is this a time-consuming effort, but it also seems not to take advantage of OO's inheritance benefits.
If I have to do this individually in each class, then I will submit my idealism (ignorance? :roll: ) to the practical reality. Before giving up, though, I really want to understand my options *and* the reasons to prefer some over others.
Thank you for your reply. I'll keep thinking about what you've suggested. In the mean time, I'm look forward to additional feedback from you and others.
As a seasoned developer, but fairly new to java, i'm feeling a bit overwhelmed by how much there is to know. I keep telling myself:
"The Big Moose Saloon is my friend!"
"The Big Moose Saloon is my friend!"
"The Big Moose Saloon is my friend!"

richard

Originally posted by Bear Bibeault:
It's more common, and would solve your problem, to have each class have its own logger. The idiom I follow in logged classes:

 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
to explain what's going on and why you get the error, I'm going to have to get somewhat theoretical
The keyword 'this' means the current instance of an object. It's therefore meaningless when talking about code that doesn't apply to any specific instance.
The keyword 'static' on the other hand means you're talking about global code that doesn't belong to any specific instance.
Therefore the two are mutually exclusive and can never be used together.
You can do several things. One is to create a single static logger which you can call from everywhere using MyLogger.log() (for example), the other is to give each class it's own static logger instance.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One of the benefits of log4j is the ability to have a hierarchical organization of loggers. By letting each class have its own named after its fully qualified class name, you have a logging hierarchy that mirrors the class hierarchy.
While thinking in object-orientation is a fine idea, you would also be tying your logging to only classes that inherit from a log-enabled base class.
If future refactoring is a concern, you can always abstract your own logging API that uses whatever your logging-du-jour package might be.
And, as you have painfully discovered, static classes and inheritance do not mix.
There are, of course, numerous other idioms that can be used. I'm surprised no one else has chimed in. (Actually, I'm not. Your topic subject isn't going to attract log4j users -- you might want to consider changing it; or perhaps posting a "How do YOU use log4j" topic).
 
Charles Richardson
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the gentle theoretical explanation. I like the idea of creating a static logger and using it everywhere (it's not my idea of an OO solution, but it does seem like an eminently practical solution ).
Aside from the non-OO aspect of the static logger idea, it would also require me to refactor all of the existing logging statement. These currently exist as:

Using the static solution, wouldn't I have to either:
  • change all these calls to "MyLogger.Log( "debug", "some message here" );
  • or create the new static logger named "logger", then give it "debug", "info", "warn", etc., methods?


  • Since the number of static classes in my effort are relatively few, I'm going to proceed with giving them individual static loggers. It seems like the quickest/easiest way to make measurable progress. Even so, I'd like to continue learning from this situation so, if there's any additional insight that you (and/or others! ) car to share, I'd be very glad to consider it.
    Thanks again for your help!
    Richard

    Originally posted by Jeroen Wenting:
    to explain what's going on and why you get the error, I'm going to have to get somewhat theoretical
    The keyword 'this' means the current instance of an object. It's therefore meaningless when talking about code that doesn't apply to any specific instance.
    The keyword 'static' on the other hand means you're talking about global code that doesn't belong to any specific instance.
    Therefore the two are mutually exclusive and can never be used together.
    You can do several things. One is to create a single static logger which you can call from everywhere using MyLogger.log() (for example), the other is to give each class it's own static logger instance.

     
    Charles Richardson
    Greenhorn
    Posts: 8
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Your point is well-taken re: hierarchical loggers. I'm even newer to log4j than I am to java so there's probably a wealth of information re: log4j that would give me a more practical perspective on this effort.
    I also appreciate your suggestion to re-post this with a "How do YOU use log4j" subject line.
    Thanks!
    Richard

    Originally posted by Bear Bibeault:
    One of the benefits of log4j is the ability to have a hierarchical organization of loggers. By letting each class have its own named after its fully qualified class name, you have a logging hierarchy that mirrors the class hierarchy.
    While thinking in object-orientation is a fine idea, you would also be tying your logging to only classes that inherit from a log-enabled base class.
    If future refactoring is a concern, you can always abstract your own logging API that uses whatever your logging-du-jour package might be.
    And, as you have painfully discovered, static classes and inheritance do not mix.
    There are, of course, numerous other idioms that can be used. I'm surprised no one else has chimed in. (Actually, I'm not. Your topic subject isn't going to attract log4j users -- you might want to consider changing it; or perhaps posting a "How do YOU use log4j" topic).

     
    reply
      Bookmark Topic Watch Topic
    • New Topic