[Hawkular-dev] Logging ...

[Peter Palaga]

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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>