> -----Original Message-----
> From: Paul Smith [mailto:[EMAIL PROTECTED]
> > 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);
> ....
> }
Which is of course the non-wrapped way to use the class. Thanks. I know given the rest
of your response, that you don't feel a wrapper is necessary. But, I believe since
Ceki mentioned it in his article, that there should be a proper way to write a
wrapper, and that is still the information I'm interested in. I appreciate your
response and how quickly you provided it, I also appreciate the advice your giving
about keeping things simple and just using log4J, but I'm not yet comfortable having
everything I'm responsible for depend directly on Log4J.
>
> 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.
Now, this has me thinking we may be on different topics, and perhaps I didn't make
myself clear. I don't have an issue with a logger for each class. I'm also pretty
content with the approach to logging which log4j has taken. So the paradigm is okay
with me, besides Ceki has demonstrated it's very close to jul. What I'm interested in
is creating a single point of package (or component) dependency such that all the
source files I'm responsible for aren't coupled to log4j (or any particular logger)
directly. [Actually I would have been okay with being coupled to a Java standard
logger interface, but I feel the standard really should have provided an api/spi
interface to logging which would have allowed me to plug log4j in as a service
provider for my logging. Oh well.] Log4J has shown itself mature, stable and feature
rich enough that I'm willing to prefer it even to JDK 1.4 logging, but I'm not
comfortable enough that I want all sources from all projects importing it directly.
Anyway, all I'm really attempting at this point is a simple wrapper which will keep
all the projects' sources I'm responsible for dependent on one "company common"
package which is in turn is dependent on Log4J. I thought such a wrapper shouldn't be
too difficult. I'm not interested in commons-logging nor do I wish to try to
re-implement it.
>
> 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.
I'm not interested in this for just one project. I have multiple products in many
different java environments (JMX, J2EE (web), Swing, J2SE, and J2EE (mail)). Since
logging is architectually significant in that it touches so many source files, I am
currently more comfortable gating logging through a common point of contact under
company control. I feel if any problems arise (or a requirement for a different
logger), I will have one place to focus on and change implementation.
>
> 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>
I'm sure your right that a lot of people (just starting out) might what a similiar
thing. Maybe it would be reasonable idea then to provide a security blanket. A
simple interface which could be repackaged for a site's own use. Most of the code
I've seen usually just uses Logger.getLogger(MyClass.class) and the simple methods
info(), debug(), etc. I could pretty easily write an interface with a nested class to
implement the factory method. It might be a little ugly, but it would keep things to
one line.
package com.mycompany.common.logging;
interface Logger {
void info(Object o);
void debug(Object o);
...
class Factory {
public Logger getLogger(Object s) {
return LogManager.getLogger(s);
}
}
}
Usage:
package com.mycompany.other;
import com.mycompany.common.logging.Logger;
class MyClass {
private static final Logger log = Logger.Factory.getLogger(MyClass.class);
...
log.debug("just like log4j, which is pretty much plug compatible with jul");
...
}
What I'm missing are the details for writing a wrapper to log4j. In this simplistic
case I could probably just subclass log4j.Logger and implement the
com.mycompany.common.logging.Logger interface. I'm just trying to get a handle on the
issues with wrapping Log4J. I see it has a method already documented for wrappers
public void log(String callerFQCN, Priority level, Object message, Throwable t);
I'm just looking for more info on writing a wrapper.
> cheers,
>
> Paul Smith
Thanks again,
Mike Rieser
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
