5:04 p.m.
Hi *, inline...
On 01/29/2015 03:32 PM, Jay Shaughnessy wrote:
By passing parameters to the message methods we defer to the generated
method impl the String concatenation involved in merging the parameters
with the static text. If String concatenation is the only extra work
being done for debug messages then we don't need any isDebugEnabled()
wrapping logic. But if it is not, meaning we need to do extra work to
generate those parameters, or if we want to conditionally execute any
other logic, we'll want to use the isDebugEnabled() wrapping.
Yes, jboss logging was designed with performance in mind. The expensive
merging of the message template with params is not performed for
disabled levels and there are no expensive varargs in game (never? or
just typically?). There was a thread on thecore about this some time ago.
Therefore, one can omit log.isXXXenabled() if there is no extra work to
generate those parameters as noted by Jay.
The thing that bothers me in this design is the log level annotation
being located with the message definition and not the logging command.
It's very convenient to scan code and see what is being logged at what
level. You may all hate the idea, but I wonder if the message method
names should incorporate a prefix with the log level. So, something like:
@LogMessage(level = Level.DEBUG)
@Message(id = 1, value = "Message received: %s")
void dMessageReceived(String msg);
Using prefixes of 't', 'd', 'i', 'w', 'e',
'f' may make the code-read
more obvious. Just a thought.
+1 I find such prefixes handy.
I'd even personaly vote for longer versions like
debugMessageReceived(String msg);
Oh, And I'd vote for "Log" as opposed to all upper or
lower ( "LOGGER",
"LOG", "log") but I don't really care.
No, CamelCase is reserved for class names in Java.
LOG is a natural choice for a static final field, but it is not really a
constant.
log is best, IMO.
-- Peter
On 1/29/2015 8:38 AM, Thomas Segismont wrote:
> Le 28/01/2015 13:47, Heiko W.Rupp a écrit :
>>> Am 28.01.2015 um 12:57 schrieb Lucas Ponce <lponce(a)redhat.com>:
>>> Also, this point can be discussed later, but is there any convention for
debug, like this one:
>>>
>>> if (LOG.isDebugEnabled()) {
>>> LOG.debug("Message received: [{}]", msg);
>>> }
>>>
>>> I mean, I like to use DEBUG for verbosity, but to reduce performance penalty,
we can discuss a common approach.
>> Isn't that relatively common usage anyway?
>> Seriously - if some code has dozens of ifDebugEnabled() calls, it may make
>> a lot of sense to factor that out to the start of the method or even in to the
constructor
>> so that this goes if (isDebug) ... { log.debug() }
>>
> As far as I understand this logging framework, parameters of the message
> should be defined as parameters of a method in the logging interface
> annotated with @MessageLogger. The method should define the logging level.
>
> If my assumption is correct, then in most cases the #isXXXEnabled calls
> can be avoided, as their purpose is to guard calls to #toString and
> String concatenation.
>
> Pursuing with Lucas' example, it should look like this:
>
> MessagingLogger.LOGGER.messageReceived(msg);
>
> With MessagingLogger looking like:
>
> @MessageLogger(projectCode = "HAWK")
> interface MessagingLogger extends BasicLogger {
>
>
> /**
> * The default logger.
> */
> MessagingLogger LOGGER = ...;
>
>
> @LogMessage(level = Level.DEBUG)
> @Message(id = 1, value = "Message received: %s")
> void messageReceived(String msg);
>
> }
>
>> Or do you mean the usage of the ugly uppercase LOG variable :-)?
> Ugly is certainly a matter of taste :p
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev