4:34 a.m.
Hi all,
I'm having a chat with Hardy about how we used the Logger in some
cases, and it turns out there's some confusion about
log.debugf vs log.debug
log.tracef vs log.trace
So the "F" variant is needed when we want to format a message, in this
case we should make sure the number of parameters matches exactly.
Also when the string is generated, like in the case of:
https://github.com/Sanne/hibernate-core/commit/3c5f8a568de99c7a6532647ab7...
it's very important that we do NOT use the formatting method, but just
a plain "log.debug( string )", otherwise it might happen at runtime
that the dynamically generated string contains some characters which
the String formatter might want interpret as placeholders, which are
missing. (HHH-6817)
In practice, it seems like a bad idea to allow a dynamically generated
formatting string at all; formatting strings as defined on the Logger
interface are safer;
In case a dynamically generated message is to be generated, we should
all make sure to pick the correct method signature; we're wondering if
there could be a reasonable proposal to make the checks of the
annotation processor stricter and validate for this, but there are
some (rare) valid use cases so just throwing compilation errors would
be nasty.
Sanne
4:44 a.m.
On Nov 23, 2011, at 11:34 , Sanne Grinovero wrote:
log.debugf vs log.debug
log.tracef vs log.trace
This also seems to be the difference between these messages with JUL:
[main ] TRACE - 11:27:51,428 - org.hibernate.loader.Loader:
org.hibernate.internal.CoreMessageLogger_$logger
[main ] TRACE - 11:27:51,429 - org.hibernate.loader.Loader: Processing result
set
[main ] DEBUG - 11:27:51,429 - org.hibernate.loader.Loader:
org.hibernate.internal.CoreMessageLogger_$logger
[main ] DEBUG - 11:27:51,429 - org.hibernate.loader.Loader:
org.hibernate.internal.CoreMessageLogger_$logger
[main ] DEBUG - 11:27:51,429 - org.hibernate.loader.Loader:
org.hibernate.internal.CoreMessageLogger_$logger
4:49 a.m.
Hi,
this revives my email from Friday
(http://lists.jboss.org/pipermail/hibernate-dev/2011-November/007307.html)
where I noticed this problem as well.
Generally speaking Sanne is of course right and the right logging method
should be used,
but does the logging framework really have to propagate the exception
thrown by String.format?
I don't think it has to. I don't think that logging should cause an
application to die.
Couldn't the Logger just catch the exception and write out the unformatted
message optionally
followed by an additional warning?
--Hardy
On Wed, 23 Nov 2011 11:34:29 +0100, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
Hi all,
I'm having a chat with Hardy about how we used the Logger in some
cases, and it turns out there's some confusion about
log.debugf vs log.debug
log.tracef vs log.trace
So the "F" variant is needed when we want to format a message, in this
case we should make sure the number of parameters matches exactly.
Also when the string is generated, like in the case of:
https://github.com/Sanne/hibernate-core/commit/3c5f8a568de99c7a6532647ab7...
it's very important that we do NOT use the formatting method, but just
a plain "log.debug( string )", otherwise it might happen at runtime
that the dynamically generated string contains some characters which
the String formatter might want interpret as placeholders, which are
missing. (HHH-6817)
In practice, it seems like a bad idea to allow a dynamically generated
formatting string at all; formatting strings as defined on the Logger
interface are safer;
In case a dynamically generated message is to be generated, we should
all make sure to pick the correct method signature; we're wondering if
there could be a reasonable proposal to make the checks of the
annotation processor stricter and validate for this, but there are
some (rare) valid use cases so just throwing compilation errors would
be nasty.
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
10:15 a.m.
The solution is really easy guys:
log.debugf("The thing I want to log is %s", thing);
or
log.debug(thing)
In addition, as you have noticed, it is better to not use the formatting
variants if you aren't actually formatting any strings (it doesn't make
a difference if the message isn't logged, but if it is there is a slight
performance boost).
As for error handling, yes, I think we should be doing somewhat better
at that. Normally this is handled by the internal logging layer but
with the variations on they types of backends and the ways they are
invoked, we should probably put this protection in at the front end as
well. I would accept a JBLOGGING JIRA to this effect.
On 11/23/2011 04:49 AM, Hardy Ferentschik wrote:
Hi,
this revives my email from Friday
(http://lists.jboss.org/pipermail/hibernate-dev/2011-November/007307.html)
where I noticed this problem as well.
Generally speaking Sanne is of course right and the right logging method
should be used,
but does the logging framework really have to propagate the exception
thrown by String.format?
I don't think it has to. I don't think that logging should cause an
application to die.
Couldn't the Logger just catch the exception and write out the
unformatted message optionally
followed by an additional warning?
--Hardy
On Wed, 23 Nov 2011 11:34:29 +0100, Sanne Grinovero
<sanne(a)hibernate.org> wrote:
> Hi all,
> I'm having a chat with Hardy about how we used the Logger in some
> cases, and it turns out there's some confusion about
>
> log.debugf vs log.debug
> log.tracef vs log.trace
>
> So the "F" variant is needed when we want to format a message, in this
> case we should make sure the number of parameters matches exactly.
>
> Also when the string is generated, like in the case of:
>
>
https://github.com/Sanne/hibernate-core/commit/3c5f8a568de99c7a6532647ab7...
>
>
> it's very important that we do NOT use the formatting method, but just
> a plain "log.debug( string )", otherwise it might happen at runtime
> that the dynamically generated string contains some characters which
> the String formatter might want interpret as placeholders, which are
> missing. (HHH-6817)
>
> In practice, it seems like a bad idea to allow a dynamically generated
> formatting string at all; formatting strings as defined on the Logger
> interface are safer;
>
> In case a dynamically generated message is to be generated, we should
> all make sure to pick the correct method signature; we're wondering if
> there could be a reasonable proposal to make the checks of the
> annotation processor stricter and validate for this, but there are
> some (rare) valid use cases so just throwing compilation errors would
> be nasty.
>
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
- DML
4:52 a.m.
On Wed, 23 Nov 2011 17:15:50 +0100, David M. Lloyd
<david.lloyd(a)redhat.com> wrote:
The solution is really easy guys:
log.debugf("The thing I want to log is %s", thing);
or
log.debug(thing)
In addition, as you have noticed, it is better to not use the formatting
variants if you aren't actually formatting any strings (it doesn't make
a difference if the message isn't logged, but if it is there is a slight
performance boost).
As for error handling, yes, I think we should be doing somewhat better
at that. Normally this is handled by the internal logging layer but
with the variations on they types of backends and the ways they are
invoked, we should probably put this protection in at the front end as
well. I would accept a JBLOGGING JIRA to this effect.
Ok, here we go - https://issues.jboss.org/browse/JBLOGGING-75 :-)
4547
days inactive
4548
days old
4 comments
4 participants
participants (4)
-
Christian Bauer -
David M. Lloyd -
Hardy Ferentschik -
Sanne Grinovero