The var-args log message construction is definitely a nice bit of
syntactic sugar, but removing the guard seems unwise; sure, there's no
string concatenation in the call to log.debug, but there's an implicit
Object[] instantiation, which isn't much better. There's a reason every
major logging API includes isLoggable/isDebugEnabled/whatever guard
methods...
L.
Don Brown wrote:
I think a couple extra classes is worth switching from this:
public Order createOrder(User user, Product product, int quantity) {
if ( log.isLoggable(Level.FINE) ) {
log.fine("Creating new order for user: " + user.username() +
" product: " + product.name() + " quantity: " +
quantity);
}
return new Order(user, product, quantity);
}
to this:
public Order createOrder(User user, Product product, int quantity) {
log.debug("Creating new order for user: #0 product: #1 quantity: #2",
user.username(), product.name(), quantity);
return new Order(user, product, quantity);
}
Considering how often we log things, I think the cleanup is huge and a
few classes are definitely worth the price.
Don
Bob Lee wrote:
On 8/22/06, Don Brown <[EMAIL PROTECTED]> wrote:
Well, for one, we only really need one logging instance for the whole
library. Second, and admittedly this is subjective, the
java.util.logging API is a horribly designed, obtuse API. I'd rather
see us write a small, clean API along the lines of Seam's logging class
that utilizes varargs to reduce the need for isDebugEnabled().
I agree that j.u.logging is a PoS, but it's ubiquitous, and for our
purposes, it workds fine. We may only need one logger for the whole
framework, but it's just as easy to create a logger per class, and you
can
still configure them all at once. I'd rather fix j.u.logging than
build yet
another API.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
