log4j wrappers

["Rieser, Michael (SCI TW)" <Mi...@stercomm.com>]

In Ceki Gülcü's article _Think Again_ I read the following statements:

	A common strategy for protecting against future changes and at
	the same time to benefit from existing log4j features is to wrap
	log4j with a custom logging API. Log4j actually has support to
	facilitate such wrappers.

	Although not particularly difficult, it turns out that wrappers
	are not trivial to write. I frequently receive email where a user
	runs into a problem with their wrapper and requests help. More
	often than not, these wrappers are of doubtful quality such
	that the cost of inactive (or disabled) logging statements
	is multiplied by a factor of 1'000 (one thousand) compared to
	direct log4j usage. The most common error in wrapper classes
	is the invocation of the Logger.getLogger method on each log
	request. This is guaranteed to wreak havoc on your application's
	performance. Really!!!

I'm very interested in some of those statements.
One is "Log4j actually has support to facilitate such wrappers."
I am interested in writing a thin wrapper for Log4J for my current
client's application.  I haven't been able to find Log4J documentation
which talks about how one would plug in a wrapper.  Could someone point
me to a relevant link?

The other statement in the same vein is "The most common error in
wrapper classes is the invocation of the Logger.getLogger method on
each log request." Along with the caveat that "This is guaranteed to
wreak havoc on your application's performance. Really!!!"

What is the preferred alternative to doing that?

My thanks to Ceki for the many articles comparing log4j and
java.util.logging I've found them very interesting. It would seem that
jul could have learned a lot, by investigating log4j more closely.
I've made a decision to stick with log4j logging, but I would like to
embrace the idea of a thin wrapper to minimize the imports throughout
our code to org.apache.log4j.

Any pointers would be appreciated. (Note: I've googled, checked the short
manual, the FAQ, the JavaDocs, and the mailing list archives without
success.)

Thanks,
Mike Rieser
Java Mentor & Architect
Michael Rieser, LLC

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

Re: log4j wrappers

[Wascally Wabbit <wa...@earthling.net>]

At 04:51 PM 3/10/2004, you wrote:

What Paul said-- particularly the advise to create two
logical kinds of logs (low-level/internal, public-facing)!

-The Wabbit


> > The other statement in the same vein is "The most common error in
> > wrapper classes is the invocation of the Logger.getLogger method on
> > each log request." Along with the caveat that "This is guaranteed to
> > wreak havoc on your application's performance. Really!!!"
> >
> > What is the preferred alternative to doing that?
> >
>
>public class MyClass {
>  private static final Logger LOG = Logger.getLogger(MyClass.class);
>....
>}
>
>Then it's available all through your code, and is only initialised once.
>
>
> > Any pointers would be appreciated. (Note: I've googled, checked the short
> > manual, the FAQ, the JavaDocs, and the mailing list archives without
> > success.)
>
>My advice, don't wrap, it's just not worth the hassle, I've created in
>the past little Util classes that hide log4j from the rest of the app
>like I am sure so many other people have.  Once you get to the point of
>really needing to know what is going on with a particular class, and
>can't deal with the volume of logging that tends to happen when an
>application grows you will thank yourself for having a separate Logger
>for each class.
>
>Note, you can always do this:
>
>public class MyClass {
>  private static final Logger CLASS_LOG =
>Logger.getLogger(MyClass.class);
>
>private static final Logger APP_LOG =
>Logger.getLogger("MyApp.LogicalSystem");
>....
>}
>
>And then log low-level DEBUGS to the CLASS_LOG, and relevant Application
>logs to the other logger (logs that have more context with the other
>logs generated by companion/related components possibly from different
>packages etc).  I am hoping the new 'Domains' concept will help make
>this a little easier to manage (coming in log4j 1.3).
>
><aside>
>Once you begin to use Log4j you will realise how incredibly useful it
>is, you will really not care about the dependency.  You can also later
>decide to use a pretty easy regexp search/replace to replace
>'org.apache.log4j' with the JDK 1.4 Logger equiv (I don't remember what
>it is, as I've never used it) if you really have issues with the
>dependency later on.
>
>This is of course 100% IMHO, and I am sure a lot of people starting out
>with log4j have the same feeling of the need to hide log4j as a
>component, but with experience I think you will find that having log4j
>as a friend for each of the classes you develop will pay off handsomely
>in the end.
></aside>
>
>cheers,
>
>Paul Smith
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org



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

Re: log4j wrappers

[Paul Smith <pa...@lawlex.com.au>]

> The other statement in the same vein is "The most common error in
> wrapper classes is the invocation of the Logger.getLogger method on
> each log request." Along with the caveat that "This is guaranteed to
> wreak havoc on your application's performance. Really!!!"
> 
> What is the preferred alternative to doing that?
> 

public class MyClass {
 private static final Logger LOG = Logger.getLogger(MyClass.class);
....
}

Then it's available all through your code, and is only initialised once.


> Any pointers would be appreciated. (Note: I've googled, checked the short
> manual, the FAQ, the JavaDocs, and the mailing list archives without
> success.)

My advice, don't wrap, it's just not worth the hassle, I've created in
the past little Util classes that hide log4j from the rest of the app
like I am sure so many other people have.  Once you get to the point of
really needing to know what is going on with a particular class, and
can't deal with the volume of logging that tends to happen when an
application grows you will thank yourself for having a separate Logger
for each class.  

Note, you can always do this:

public class MyClass {
 private static final Logger CLASS_LOG =
Logger.getLogger(MyClass.class);

private static final Logger APP_LOG =
Logger.getLogger("MyApp.LogicalSystem");
....
}

And then log low-level DEBUGS to the CLASS_LOG, and relevant Application
logs to the other logger (logs that have more context with the other
logs generated by companion/related components possibly from different
packages etc).  I am hoping the new 'Domains' concept will help make
this a little easier to manage (coming in log4j 1.3).

<aside>
Once you begin to use Log4j you will realise how incredibly useful it
is, you will really not care about the dependency.  You can also later
decide to use a pretty easy regexp search/replace to replace
'org.apache.log4j' with the JDK 1.4 Logger equiv (I don't remember what
it is, as I've never used it) if you really have issues with the
dependency later on.

This is of course 100% IMHO, and I am sure a lot of people starting out
with log4j have the same feeling of the need to hide log4j as a
component, but with experience I think you will find that having log4j
as a friend for each of the classes you develop will pay off handsomely
in the end.
</aside>

cheers,

Paul Smith 


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