You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2006/08/22 13:01:02 UTC
Whose log is this anyway? (was Re: [s1] Commons-Lang)
On 8/22/06, Don Brown <do...@gmail.com> wrote:
> At some point, I plan to replace commons-logging in Struts 2 with a
> simple log framework. I can backport to Struts 1 if desired.
Why not just import the org.apache.common.logging source code and
rename it o.a.struts.logging? That way we don't have to learn anything
new, and if a improved version were to come out, we can replace it all
wholesale.
Say, wasn't there a mention of some package that renamed packages
dynamically or something? That's the real issue. Two versions of the
same package name on the same classpath.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Bob Lee <cr...@crazybob.org>.
+1 for varargs. We can always extend j.u.logging.Logger and add these
methods.
On 8/22/06, Tim Fennell <tf...@tfenne.com> wrote:
>
> I can't agree enough with using var-args for logging. Stripes has,
> from the start, done something very similar to Seam. The main
> difference is that instead of putting placeholders into the message,
> you just provide things in the order you want appended. I find that
> convenient because you basically replace +s with commas. The class
> in question is here:
>
> http://svn.sourceforge.net/viewvc/stripes/trunk/stripes/src/net/
> sourceforge/stripes/util/Log.java?revision=292&view=markup
>
> Note, that using var-args not only allows you to be more concise, but
> you can also do intelligent things like use Arrays.toString to get
> meaningful info for arrays etc.
>
> Regardless of what you use underneath (commons, jdk,
> PrintWriter),having a nice clean logger interface really helps keep
> the framework code cleaner and easier to read.
>
> -t
>
> On Aug 22, 2006, at 12:22 PM, Don Brown 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().
> >
> > http://docs.jboss.com/seam/latest/reference/en/html/
> > concepts.html#d0e2598
> >
> > Don
> >
> > Bob Lee wrote:
> >> How is j.u.logging overkill, especially considering using it would
> >> mean one
> >> less dependency? From our standpoint, the only thing we care about
> >> is Logger
> >> anyway.
> >>
> >> Bob
> >>
> >> On 8/22/06, Don Brown <mr...@twdata.org> wrote:
> >>>
> >>> I'd rather use java.util.logging than commons-logging, but I
> >>> think both
> >>> are overkill for a library. I think Nathan is spot on and we should
> >>> look to using Velocity's logging classes, imported into our
> >>> codebase.
> >>> The whole logging "framework" we'd need would be like two or three
> >>> classes.
> >>>
> >>> Jarjar would also be nice, perhaps in conjunction with Velocity's
> >>> logging classes. It would help us solve the xwork version
> >>> problem nicely.
> >>>
> >>> Don
> >>>
> >>> Bob Lee wrote:
> >>> > On 8/22/06, Ted Husted <hu...@apache.org> wrote:
> >>> >>
> >>> >> Say, wasn't there a mention of some package that renamed packages
> >>> >> dynamically or something? That's the real issue. Two versions
> >>> of the
> >>> >> same package name on the same classpath.
> >>> >
> >>> >
> >>> > jarjar
> >>> >
> >>> > In the case of logging though, we should just use
> >>> java.util.logging.
> >>> >
> >>> > If you still want to use log4j, why not write a j.u.logging
> >>> Handler
> >>> which
> >>> > logs to log4j? Do we really need an API to decouple us from an
> >>> API which
> >>> > decouples us from a logging implementation, or is one level of
> >>> > indirection
> >>> > sufficient? This is why everyone makes fun of clogging.
> >>> >
> >>> > Bob
> >>> >
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Tim Fennell <tf...@tfenne.com>.
I can't agree enough with using var-args for logging. Stripes has,
from the start, done something very similar to Seam. The main
difference is that instead of putting placeholders into the message,
you just provide things in the order you want appended. I find that
convenient because you basically replace +s with commas. The class
in question is here:
http://svn.sourceforge.net/viewvc/stripes/trunk/stripes/src/net/
sourceforge/stripes/util/Log.java?revision=292&view=markup
Note, that using var-args not only allows you to be more concise, but
you can also do intelligent things like use Arrays.toString to get
meaningful info for arrays etc.
Regardless of what you use underneath (commons, jdk,
PrintWriter),having a nice clean logger interface really helps keep
the framework code cleaner and easier to read.
-t
On Aug 22, 2006, at 12:22 PM, Don Brown 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().
>
> http://docs.jboss.com/seam/latest/reference/en/html/
> concepts.html#d0e2598
>
> Don
>
> Bob Lee wrote:
>> How is j.u.logging overkill, especially considering using it would
>> mean one
>> less dependency? From our standpoint, the only thing we care about
>> is Logger
>> anyway.
>>
>> Bob
>>
>> On 8/22/06, Don Brown <mr...@twdata.org> wrote:
>>>
>>> I'd rather use java.util.logging than commons-logging, but I
>>> think both
>>> are overkill for a library. I think Nathan is spot on and we should
>>> look to using Velocity's logging classes, imported into our
>>> codebase.
>>> The whole logging "framework" we'd need would be like two or three
>>> classes.
>>>
>>> Jarjar would also be nice, perhaps in conjunction with Velocity's
>>> logging classes. It would help us solve the xwork version
>>> problem nicely.
>>>
>>> Don
>>>
>>> Bob Lee wrote:
>>> > On 8/22/06, Ted Husted <hu...@apache.org> wrote:
>>> >>
>>> >> Say, wasn't there a mention of some package that renamed packages
>>> >> dynamically or something? That's the real issue. Two versions
>>> of the
>>> >> same package name on the same classpath.
>>> >
>>> >
>>> > jarjar
>>> >
>>> > In the case of logging though, we should just use
>>> java.util.logging.
>>> >
>>> > If you still want to use log4j, why not write a j.u.logging
>>> Handler
>>> which
>>> > logs to log4j? Do we really need an API to decouple us from an
>>> API which
>>> > decouples us from a logging implementation, or is one level of
>>> > indirection
>>> > sufficient? This is why everyone makes fun of clogging.
>>> >
>>> > Bob
>>> >
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Nathan Bubna <nb...@gmail.com>.
+1 I really like what Seam is doing. As soon as Velocity moves to
jdk5, you can bet we'll be doing much the same.
And yeah, it really only takes a few simple classes to have a much
nicer interface than j.u.logging. For Velocity, we basically have
two classes (Log and LogManager) and an interface (LogChute), then the
rest are all just very simple LogChute implementations to j.u.logging,
clogging and such. Adding the ability to use varargs to streamline
things as Seam and Stripes are doing would definitely make it
worthwhile to implement this, IMHO.
On 8/22/06, Don Brown <mr...@twdata.org> 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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Martin Cooper <ma...@apache.org>.
On 8/23/06, Ted Husted <hu...@apache.org> wrote:
>
> On 8/23/06, Erik Bertelsen <be...@gmail.com> wrote:
> > this is exactly my concern in this discussion: I want to be able to
> > control all logging from my application in one place.
>
> The question is whether Struts (and XWork and Spring) should count as
> part of "your application" or not.
>
> What's being proposed is that we take Struts out of the "my
> application" logging loop, so that you are free to do whatever you
> like with your own application.
I hope that's not really what's being proposed. If something goes wrong in
my Struts app, I don't want to have to manually correlate error messages
from the Struts log and those from my app's log. It's crucial that I have a
unified log for my entire application. Hopefully I'm misunderstanding you
and I'll still be able to do that.
--
Martin Cooper
-Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Ted Husted <hu...@apache.org>.
On 8/23/06, Erik Bertelsen <be...@gmail.com> wrote:
> this is exactly my concern in this discussion: I want to be able to
> control all logging from my application in one place.
The question is whether Struts (and XWork and Spring) should count as
part of "your application" or not.
What's being proposed is that we take Struts out of the "my
application" logging loop, so that you are free to do whatever you
like with your own application.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Erik Bertelsen <be...@gmail.com>.
2006/8/22, Martin Cooper <ma...@apache.org>:
>
>
>
> As long as the log output and log configuration for my end application is
> unified - so Struts output and Commons component output go to the same
> place
> - then I'm OK with using something other than Commons Logging, if we have
> to.
Dear all,
this is exactly my concern in this discussion: I want to be able to
control all logging from my application in one place. For me Commons Logging
has been a way to achieve this except for one third part package that
decided to use java.util.Logging explicitly where everything else uses
commons-logging which in turn is calling log4j at my choice.
I don't care too much whether I have to use java.util.Logging or something
else, but one log configuration file and (if I want it) one log file per
application is my requirement.
Of course I expect any changes in Struts logging to continuing to support
this and also to play well with the application container (in my case
Tomcat).
regards
- Erik
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Martin Cooper <ma...@apache.org>.
On 8/22/06, Don Brown <mr...@twdata.org> 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);
> }
I suppose it was an accident that you spread the log.fine call over 3 lines,
but used one much longer line for the log.debug example? Stretching a point
perhaps? ;-)
As long as the log output and log configuration for my end application is
unified - so Struts output and Commons component output go to the same place
- then I'm OK with using something other than Commons Logging, if we have
to.
--
Martin Cooper
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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Bob Lee <cr...@crazybob.org>.
On 8/22/06, Don Brown <mr...@twdata.org> wrote:
>
> Well, I don't think adding external deps was ever on the table as the
> discussion was prompted by wanting to get rid of them :) I'm fine with
> extending j.u.logging, but would plan to add isDebugEnabled and debug
> methods :)
Sounds great.
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Don Brown <mr...@twdata.org>.
Bob Lee wrote:
> I thought we were talking about logging for Struts internals. Are we
> talking
> about also exposing a utility class of some sort to users? Or is this
> just
> an example?
This is just an example.
>
> Like I said in the other email, I'm all for varargs, but we should
> probably
> just hard code it to j.u.logging and not worry about getting too fancy
> and/or adding external deps.
Well, I don't think adding external deps was ever on the table as the
discussion was prompted by wanting to get rid of them :) I'm fine with
extending j.u.logging, but would plan to add isDebugEnabled and debug
methods :)
Don
>
>
> Bob
>
> On 8/22/06, Don Brown <mr...@twdata.org> 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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Bob Lee <cr...@crazybob.org>.
I thought we were talking about logging for Struts internals. Are we talking
about also exposing a utility class of some sort to users? Or is this just
an example?
Like I said in the other email, I'm all for varargs, but we should probably
just hard code it to j.u.logging and not worry about getting too fancy
and/or adding external deps.
Bob
On 8/22/06, Don Brown <mr...@twdata.org> 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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Nathan Bubna <nb...@gmail.com>.
On 8/22/06, Martin Cooper <ma...@apache.org> wrote:
> On 8/22/06, Tim Fennell <tf...@tfenne.com> wrote:
> >
> > On Aug 22, 2006, at 5:11 PM, Martin Cooper wrote:
> >
> > > if (isDebugLoggingEnabled()) {
> > > log.debug("And the answer is: " + expensiveMethodCallHere());
> > > }
> > >
> > > I don't know about you, but I'm very thankful for that guard when
> > > debug
> > > logging is disabled (e.g. in production). Without it, I'm going to
> > > make that
> > > expensive method call even if logging is disabled - and then just
> > > throw away
> > > the result after doing nothing in log.debug. Even a lowly toString
> > > () call,
> > > frequently used in debug logging, can get expensive, so it's not
> > > like this
> > > is a corner case.
> > >
> > > -1 on getting rid of guards.
> >
> > I agree that in rare cases you might want to be able to do this
> > still. But in the vastly more common 2nd case you cite (the
> > expensive toString() call), that's entirely the point of this. Log
> > methods take Object.../Object[] and only toString the objects in the
> > array if the appropriate log level is enabled.
>
>
> No, I don't think you're getting what I'm saying. I'm not talking about
> internal toString() calls, I'm talking about something like:
>
> log.debug("And the answer is: " + myBigObject.toString());
>
> That toString() method is going to be invoked before the log.debug method is
> ever called, so the cost is sunk even if debug logging is disabled.
>
> Now, I get the point that I should probably have used a parameterised string
> and passed in myBigObject, letting the log method to the toString() call,
> but people are so used to doing things like the above that it will still
> happen.
True. Also true is that the same people are also used to wrapping
such calls in isDebugEnabled() which i don't think anyone wants to
abolish. They just want a shorthand to be available. Besides, we are
still talking about the internal logging facility for Struts2 (and
potentially directly tied derivate libraries), not something
application developers are supposed to be using, right?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Bob Lee <cr...@crazybob.org>.
On 8/22/06, Tim Fennell <tf...@tfenne.com> wrote:
>
> log.debug("And the answer is: ", myBigObject, " (didn't you
> guess?).");
I like that.
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Tim Fennell <tf...@tfenne.com>.
Why does a difference of opinion always have to lead to someone
saying "I don't think you get what I'm saying"? Sigh. I get it just
fine, I just disagree.
So what you're saying effectively is that developers who are smart
enough/well trained enough to know to wrap expensive logging
statements in a guard will not be smart enough/remember to use a
different logging method signature?
At any rate, while the Seam style looks nice after the fact, I do
tend to think that's it more of a pain to write with placeholders and
all. I use a syntax like this:
log.debug("And the answer is: ", myBigObject, " (didn't you
guess?).");
So that all you're really doing is replacing + symbols with commas,
and getting the same benefit.
-t
On Aug 22, 2006, at 5:26 PM, Martin Cooper wrote:
> No, I don't think you're getting what I'm saying. I'm not talking
> about
> internal toString() calls, I'm talking about something like:
>
> log.debug("And the answer is: " + myBigObject.toString());
>
> That toString() method is going to be invoked before the log.debug
> method is
> ever called, so the cost is sunk even if debug logging is disabled.
>
> Now, I get the point that I should probably have used a
> parameterised string
> and passed in myBigObject, letting the log method to the toString()
> call,
> but people are so used to doing things like the above that it will
> still
> happen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Martin Cooper <ma...@apache.org>.
On 8/22/06, Tim Fennell <tf...@tfenne.com> wrote:
>
> On Aug 22, 2006, at 5:11 PM, Martin Cooper wrote:
>
> > if (isDebugLoggingEnabled()) {
> > log.debug("And the answer is: " + expensiveMethodCallHere());
> > }
> >
> > I don't know about you, but I'm very thankful for that guard when
> > debug
> > logging is disabled (e.g. in production). Without it, I'm going to
> > make that
> > expensive method call even if logging is disabled - and then just
> > throw away
> > the result after doing nothing in log.debug. Even a lowly toString
> > () call,
> > frequently used in debug logging, can get expensive, so it's not
> > like this
> > is a corner case.
> >
> > -1 on getting rid of guards.
>
> I agree that in rare cases you might want to be able to do this
> still. But in the vastly more common 2nd case you cite (the
> expensive toString() call), that's entirely the point of this. Log
> methods take Object.../Object[] and only toString the objects in the
> array if the appropriate log level is enabled.
No, I don't think you're getting what I'm saying. I'm not talking about
internal toString() calls, I'm talking about something like:
log.debug("And the answer is: " + myBigObject.toString());
That toString() method is going to be invoked before the log.debug method is
ever called, so the cost is sunk even if debug logging is disabled.
Now, I get the point that I should probably have used a parameterised string
and passed in myBigObject, letting the log method to the toString() call,
but people are so used to doing things like the above that it will still
happen.
--
Martin Cooper
-t
>
>
>
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Tim Fennell <tf...@tfenne.com>.
On Aug 22, 2006, at 5:11 PM, Martin Cooper wrote:
> if (isDebugLoggingEnabled()) {
> log.debug("And the answer is: " + expensiveMethodCallHere());
> }
>
> I don't know about you, but I'm very thankful for that guard when
> debug
> logging is disabled (e.g. in production). Without it, I'm going to
> make that
> expensive method call even if logging is disabled - and then just
> throw away
> the result after doing nothing in log.debug. Even a lowly toString
> () call,
> frequently used in debug logging, can get expensive, so it's not
> like this
> is a corner case.
>
> -1 on getting rid of guards.
I agree that in rare cases you might want to be able to do this
still. But in the vastly more common 2nd case you cite (the
expensive toString() call), that's entirely the point of this. Log
methods take Object.../Object[] and only toString the objects in the
array if the appropriate log level is enabled.
-t
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Don Brown <mr...@twdata.org>.
This isn't an either/or decision. As I said before, there certainly are
cases where the guard is necessary and your example highlights one of
them. However, in most cases, it isn't and these cases could use a more
compact var-args logging call.
Don
Martin Cooper wrote:
> On 8/22/06, Tim Fennell <tf...@tfenne.com> wrote:
>>
>> To add a little weight to Don's comments, the cost of allocating an
>> array really is *very* minor. To quote Brian Goetz[1], the cost of
>> allocating a new object in 1.4.2 and above is approximately 10
>> instructions (maybe more for an array, but remember that var-arg
>> calls are optimized at compile time). And more to the point, since
>> it's lifetime is very short, the GC overhead is most often zero. So
>> the overhead is minor at best.
>
>
> In that particular case, yes. However, consider the following:
>
> if (isDebugLoggingEnabled()) {
> log.debug("And the answer is: " + expensiveMethodCallHere());
> }
>
> I don't know about you, but I'm very thankful for that guard when debug
> logging is disabled (e.g. in production). Without it, I'm going to
> make that
> expensive method call even if logging is disabled - and then just
> throw away
> the result after doing nothing in log.debug. Even a lowly toString()
> call,
> frequently used in debug logging, can get expensive, so it's not like
> this
> is a corner case.
>
> -1 on getting rid of guards.
>
> --
> Martin Cooper
>
>
> -t
>>
>> [1] http://www-128.ibm.com/developerworks/java/library/j-
>> jtp09275.html#resources
>>
>>
>> On Aug 22, 2006, at 4:21 PM, Don Brown wrote:
>>
>> > There will always be cases where the isDebugEnabled method will be
>> > necessary, but for the vast majority of cases, I think the varargs
>> > solution is perfect. The very minor cost of an Object array, IMO,
>> > is well worth the value of code clarity, simplicity, and
>> > maintainability.
>> >
>> > Don
>> >
>> > Laurie Harper wrote:
>> >> 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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Martin Cooper <ma...@apache.org>.
On 8/22/06, Tim Fennell <tf...@tfenne.com> wrote:
>
> To add a little weight to Don's comments, the cost of allocating an
> array really is *very* minor. To quote Brian Goetz[1], the cost of
> allocating a new object in 1.4.2 and above is approximately 10
> instructions (maybe more for an array, but remember that var-arg
> calls are optimized at compile time). And more to the point, since
> it's lifetime is very short, the GC overhead is most often zero. So
> the overhead is minor at best.
In that particular case, yes. However, consider the following:
if (isDebugLoggingEnabled()) {
log.debug("And the answer is: " + expensiveMethodCallHere());
}
I don't know about you, but I'm very thankful for that guard when debug
logging is disabled (e.g. in production). Without it, I'm going to make that
expensive method call even if logging is disabled - and then just throw away
the result after doing nothing in log.debug. Even a lowly toString() call,
frequently used in debug logging, can get expensive, so it's not like this
is a corner case.
-1 on getting rid of guards.
--
Martin Cooper
-t
>
> [1] http://www-128.ibm.com/developerworks/java/library/j-
> jtp09275.html#resources
>
>
> On Aug 22, 2006, at 4:21 PM, Don Brown wrote:
>
> > There will always be cases where the isDebugEnabled method will be
> > necessary, but for the vast majority of cases, I think the varargs
> > solution is perfect. The very minor cost of an Object array, IMO,
> > is well worth the value of code clarity, simplicity, and
> > maintainability.
> >
> > Don
> >
> > Laurie Harper wrote:
> >> 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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Tim Fennell <tf...@tfenne.com>.
To add a little weight to Don's comments, the cost of allocating an
array really is *very* minor. To quote Brian Goetz[1], the cost of
allocating a new object in 1.4.2 and above is approximately 10
instructions (maybe more for an array, but remember that var-arg
calls are optimized at compile time). And more to the point, since
it's lifetime is very short, the GC overhead is most often zero. So
the overhead is minor at best.
-t
[1] http://www-128.ibm.com/developerworks/java/library/j-
jtp09275.html#resources
On Aug 22, 2006, at 4:21 PM, Don Brown wrote:
> There will always be cases where the isDebugEnabled method will be
> necessary, but for the vast majority of cases, I think the varargs
> solution is perfect. The very minor cost of an Object array, IMO,
> is well worth the value of code clarity, simplicity, and
> maintainability.
>
> Don
>
> Laurie Harper wrote:
>> 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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Don Brown <mr...@twdata.org>.
There will always be cases where the isDebugEnabled method will be
necessary, but for the vast majority of cases, I think the varargs
solution is perfect. The very minor cost of an Object array, IMO, is
well worth the value of code clarity, simplicity, and maintainability.
Don
Laurie Harper wrote:
> 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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Laurie Harper <la...@holoweb.net>.
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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Don Brown <mr...@twdata.org>.
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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Niall Pemberton <ni...@gmail.com>.
I created an issue ticket for this - and attached an implementation:
https://issues.apache.org/struts/browse/WW-1413
Niall
On 8/23/06, Niall Pemberton <ni...@gmail.com> wrote:
> On 8/22/06, Bob Lee <cr...@crazybob.org> wrote:
> > On 8/22/06, Don Brown <mr...@twdata.org> 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.
>
> Patrick blogged recently [1] about creating a wrapper for j.u.logging
> and the issue he encountered. Looking at the j.u.logging
> implementation in Commons Logging [2] - they resolved the issue he hit
> by determining the class/method from the stack trace and using the
> logp methods - rather than leaving j.u.logging to fill those values
> in.
>
> Niall
>
> [1] http://tinyurl.com/o7yqp
> [2] http://tinyurl.com/oup4w
>
>
> > Bob
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Niall Pemberton <ni...@gmail.com>.
On 8/22/06, Bob Lee <cr...@crazybob.org> wrote:
> On 8/22/06, Don Brown <mr...@twdata.org> 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.
Patrick blogged recently [1] about creating a wrapper for j.u.logging
and the issue he encountered. Looking at the j.u.logging
implementation in Commons Logging [2] - they resolved the issue he hit
by determining the class/method from the stack trace and using the
logp methods - rather than leaving j.u.logging to fill those values
in.
Niall
[1] http://tinyurl.com/o7yqp
[2] http://tinyurl.com/oup4w
> Bob
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Bob Lee <cr...@crazybob.org>.
On 8/22/06, Don Brown <mr...@twdata.org> 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
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Don Brown <mr...@twdata.org>.
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().
http://docs.jboss.com/seam/latest/reference/en/html/concepts.html#d0e2598
Don
Bob Lee wrote:
> How is j.u.logging overkill, especially considering using it would
> mean one
> less dependency? From our standpoint, the only thing we care about is
> Logger
> anyway.
>
> Bob
>
> On 8/22/06, Don Brown <mr...@twdata.org> wrote:
>>
>> I'd rather use java.util.logging than commons-logging, but I think both
>> are overkill for a library. I think Nathan is spot on and we should
>> look to using Velocity's logging classes, imported into our codebase.
>> The whole logging "framework" we'd need would be like two or three
>> classes.
>>
>> Jarjar would also be nice, perhaps in conjunction with Velocity's
>> logging classes. It would help us solve the xwork version problem
>> nicely.
>>
>> Don
>>
>> Bob Lee wrote:
>> > On 8/22/06, Ted Husted <hu...@apache.org> wrote:
>> >>
>> >> Say, wasn't there a mention of some package that renamed packages
>> >> dynamically or something? That's the real issue. Two versions of the
>> >> same package name on the same classpath.
>> >
>> >
>> > jarjar
>> >
>> > In the case of logging though, we should just use java.util.logging.
>> >
>> > If you still want to use log4j, why not write a j.u.logging Handler
>> which
>> > logs to log4j? Do we really need an API to decouple us from an API
>> which
>> > decouples us from a logging implementation, or is one level of
>> > indirection
>> > sufficient? This is why everyone makes fun of clogging.
>> >
>> > Bob
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Bob Lee <cr...@crazybob.org>.
How is j.u.logging overkill, especially considering using it would mean one
less dependency? From our standpoint, the only thing we care about is Logger
anyway.
Bob
On 8/22/06, Don Brown <mr...@twdata.org> wrote:
>
> I'd rather use java.util.logging than commons-logging, but I think both
> are overkill for a library. I think Nathan is spot on and we should
> look to using Velocity's logging classes, imported into our codebase.
> The whole logging "framework" we'd need would be like two or three
> classes.
>
> Jarjar would also be nice, perhaps in conjunction with Velocity's
> logging classes. It would help us solve the xwork version problem nicely.
>
> Don
>
> Bob Lee wrote:
> > On 8/22/06, Ted Husted <hu...@apache.org> wrote:
> >>
> >> Say, wasn't there a mention of some package that renamed packages
> >> dynamically or something? That's the real issue. Two versions of the
> >> same package name on the same classpath.
> >
> >
> > jarjar
> >
> > In the case of logging though, we should just use java.util.logging.
> >
> > If you still want to use log4j, why not write a j.u.logging Handler
> which
> > logs to log4j? Do we really need an API to decouple us from an API which
> > decouples us from a logging implementation, or is one level of
> > indirection
> > sufficient? This is why everyone makes fun of clogging.
> >
> > Bob
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Patrick Lightbody <fo...@opensymphony.com>.
Whatever Struts ends up doing, we'll also do in XWork.
> On 8/22/06, Don Brown <mr...@twdata.org> wrote:
> > I'd rather use java.util.logging than
> commons-logging, but I think both
> > are overkill for a library.
>
> Of course, our library is an extension of the XWork
> library.
>
> Do we want to cooridnate what we do here with what
> XWork 2 does / should do?
>
> Otherwise, are not Commons Logging and Log4J going to
> come in through
> the XWork backdoor, bring all the same problems
> along?
>
> What does Spring do about logging?
>
> -Ted.
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> dev-unsubscribe@struts.apache.org
> For additional commands, e-mail:
> dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=40994&messageID=81971#81971
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Ted Husted <hu...@apache.org>.
On 8/22/06, Don Brown <mr...@twdata.org> wrote:
> I'd rather use java.util.logging than commons-logging, but I think both
> are overkill for a library.
Of course, our library is an extension of the XWork library.
Do we want to cooridnate what we do here with what XWork 2 does / should do?
Otherwise, are not Commons Logging and Log4J going to come in through
the XWork backdoor, bring all the same problems along?
What does Spring do about logging?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Don Brown <mr...@twdata.org>.
I'd rather use java.util.logging than commons-logging, but I think both
are overkill for a library. I think Nathan is spot on and we should
look to using Velocity's logging classes, imported into our codebase.
The whole logging "framework" we'd need would be like two or three classes.
Jarjar would also be nice, perhaps in conjunction with Velocity's
logging classes. It would help us solve the xwork version problem nicely.
Don
Bob Lee wrote:
> On 8/22/06, Ted Husted <hu...@apache.org> wrote:
>>
>> Say, wasn't there a mention of some package that renamed packages
>> dynamically or something? That's the real issue. Two versions of the
>> same package name on the same classpath.
>
>
> jarjar
>
> In the case of logging though, we should just use java.util.logging.
>
> If you still want to use log4j, why not write a j.u.logging Handler which
> logs to log4j? Do we really need an API to decouple us from an API which
> decouples us from a logging implementation, or is one level of
> indirection
> sufficient? This is why everyone makes fun of clogging.
>
> Bob
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Nathan Bubna <nb...@gmail.com>.
Very cool. That looks like what i was looking for. Thanks :)
On 8/22/06, Bob Lee <cr...@crazybob.org> wrote:
> On 8/22/06, Ted Husted <hu...@apache.org> wrote:
> >
> > Say, wasn't there a mention of some package that renamed packages
> > dynamically or something? That's the real issue. Two versions of the
> > same package name on the same classpath.
>
>
> jarjar
>
> In the case of logging though, we should just use java.util.logging.
>
> If you still want to use log4j, why not write a j.u.logging Handler which
> logs to log4j? Do we really need an API to decouple us from an API which
> decouples us from a logging implementation, or is one level of indirection
> sufficient? This is why everyone makes fun of clogging.
>
> Bob
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Whose log is this anyway? (was Re: [s1] Commons-Lang)
Posted by Bob Lee <cr...@crazybob.org>.
On 8/22/06, Ted Husted <hu...@apache.org> wrote:
>
> Say, wasn't there a mention of some package that renamed packages
> dynamically or something? That's the real issue. Two versions of the
> same package name on the same classpath.
jarjar
In the case of logging though, we should just use java.util.logging.
If you still want to use log4j, why not write a j.u.logging Handler which
logs to log4j? Do we really need an API to decouple us from an API which
decouples us from a logging implementation, or is one level of indirection
sufficient? This is why everyone makes fun of clogging.
Bob