Women in Technology

Hear us Roar



Article:
  Understanding Classloaders: log4j in a J2EE Environment
Subject:   You still haven't addressed the most important thing....
Date:   2003-04-11 05:09:34
From:   gvix
Response to: You still haven't addressed the most important thing....

Hello,


Thanks for the feedback.


The articles main idea was to understand classloading issues and not act as a manual for all the issues involved in J2EE packaging and deployment.


I agree that log4j in a cluster is an issue. However, it can be addressed by using either SocketAppender or JMX.


I disagree when you say that log4j is not mature. There needs to be more to substantiate that claim than lack of genuine cluster support.


Regards,
Vikram Goyal

Main Topics Oldest First

Showing messages 1 through 2 of 2.

  • log4j in a cluster is an issue?
    2003-04-18 11:10:45  anonymous2 [View]

    Hello Vikram,

    I have enjoyed both of your articles. I am new to log4j and researching it for use across my company's applications.

    We are running WebLogic clustered, so I am wondering what you mean when you say "I agree that log4j in a cluster is an issue"? What are the issues related to clustering??

    Thanks,

    - darryl
  • You still haven't addressed the most important thing....
    2003-04-17 07:53:07  anonymous2 [View]

    Vikram,

    This was a good topic to cover, thanks, classloading for J2EE is a constant source of troubles and frustrations and any clarifications are appreciated. I'd like to see a chapter or entire book written on the best way to organize classes in a J2EE app.

    I must agree with the original point in this thread. Logging should be provided by J2EE as an app server service.

    My recommendation would be to log using your own api (abstract factory pattern) which can then be implemented to use either the app severs logging capabilities, or log4j, or the jdk 1.4 logging. An example of why this would be useful would be log4j's own fickleness in it's api. First it was "Category" and now it's "Logger". It would be nice if they'd just make up their minds, but if you placed a protective layer between your app and logging implementation, you can update to the latest version by changing "category" to "logger" in one file.

    BTW: What we need is logging that knows which class it's in without the developer having to specify it. Taking the classloading and that together, log4j is sometimes more trouble than it's worth.

    Taylor