And what about the logging packages ? > import org.jboss.logging.*; vs import org.slf4j.Logger; import org.slf4j.LoggerFactory; I personally vote for org.slf4j. I prefer a mix on option 1) and 2), a common numeration for codes, but each component can still using a specific acronym. That it can help better to follow traces/logs. 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. Above one is just a suggestion. Thanks, Lucas ----- Original Message ----- > From: "Heiko W.Rupp" <hrupp(a)redhat.com&gt; > To: hawkular-dev(a)lists.jboss.org > Sent: Wednesday, January 28, 2015 12:48:26 PM > Subject: [Hawkular-dev] Logging ... > > Hey, > > We should / need to start using logging codes just like Wildfly does. > > 11:19:27,714 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- > 31) WFLYIO001: Worker 'default' has auto-configured to 8 core threads with > 64 task threads based on your 4 available processors > 11:19:27,716 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread > Pool -- 32) JBAS010280: Activating Infinispan subsystem. > > We have two options here > > 1) > We use "HAWK" as our prefix and the following code ranges initially > > 0-999 Hawkular (integration) > 1000-1999 Hawkular-Metrics > 2000-2999 Hawkular-Alerts (notifiers should probably be broken out in > separate blocks) > 3000-3999 Hawkular-Inventory > 4000-4999 Hawkular-Bus > > 2) > We use a prefix per component (e.g. HAWK, HKMET, HKAL, ...) and each > component has its own code range starting > at 0 > > Personally I prefer option 1 > > There is already documentation on this available > > • https://developer.jboss.org/wiki/HowToLogInJBossProjects > • https://developer.jboss.org/wiki/InternationalizedLoggingAndExceptions > • https://developer.jboss.org/wiki/JBossLoggingTooling > > While the documentation and examples look a bit complicated, I think we can > "reduce" them for > our purpose for Warnings and Errors and do not need them on debug/trace > level. > For info level I guess one should personal judgement (and then if it is not > important enough for > its own code, it is probably not really something at info, but rather at > debug level). > > In practice we would probably end up with something like: > > import org.jboss.logging.*; > public interface RestApiLogger { > > RestApiLogger LOGGER = > Logger.getMessageLogger(RestApiLogger.class,"org.hawkular.inventory.rest"); > > @LogMessage(level = Logger.Level.WARN) > @Message(id = 3000, value = "Something bad has happened") > void warn(@Cause Throwable t); > > < plus much more refined messages here > > } > > and then in code > > } catch (Exception e) { > RestApiLogger.LOGGER.warn(e); > return Response.serverError().entity(e).build(); > } > > > > -- > Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, > Werner-von-Siemens-Ring 14, D-85630 Grasbrunn > Handelsregister: Amtsgericht München HRB 153243 > Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie > Peters > > > _______________________________________________ > 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

> Am 28.01.2015 um 12:57 schrieb Lucas Ponce <lponce(a)redhat.com&gt;: > 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() }

Or do you mean the usage of the ugly uppercase LOG variable :-)?

_______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

This page shows how you can put this in your pom.xml to process the message bundles: https://developer.jboss.org/wiki/JBossLoggingTooling#jive_content_id_mave... And this is a good snippet that shows how org.jboss.logging is used: @MessageLogger("JBREM") public interface MyLogger { @Message(id = 1, value = "JBoss Remoting version %s") @LogMessage(level = INFO) void greet(String version); @Message(id = 2, value = "Error connecting from %s to %s: %s") @LogMessage(level = ERROR) void connectionError(SocketAddress src, SocketAddress dst, String reason); // trace stuff has different restrictions @Message(value = "Connection established from %s to %s") @LogMessage(level = TRACE) void connectionEstablished(SocketAddress src, SocketAddress dst); // THIS SHOWS USING @Cause @LogMessage(level = Level.ERROR) @Message(id = 3, value = "Error Message: %s") void errorWithCause(@Cause Throwable cause, String error); } public class Foo { MyLogger log; static { log = Logger.getMessageLogger(MyLogger.class, "org.jboss.remoting"); // defaults to current locale log.greet(getVersionString()); // etc. } } _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

> Am 28.01.2015 um 12:57 schrieb Lucas Ponce <lponce(a)redhat.com&gt;: > 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() }

Or do you mean the usage of the ugly uppercase LOG variable :-)?

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.

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.

Oh, And I'd vote for "Log" as opposed to all upper or lower ( "LOGGER", "LOG", "log") but I don't really care.

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&gt;: >>> 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

Am 29.01.2015 um 15:32 schrieb Jay Shaughnessy <jshaughn(a)redhat.com&gt;: 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