Develop Reference

How to solve this issue "Standard outputs should not be used directly to log anything "

I need a print statement. But sonar not allowed this type.
String txt="Something";
System.out.println("Print: "+txt);
Expected output:
Print: Something
I tried this format logger.log().its not working for our requirement.

Sonarqube does not like it if you use System.out, or if you have string concatenation or other computation in the arguments you pass to the logging function. Construct the full message on a separate line before logging it:
String txt = "Print: " + "Something";
String logMessage = "Print: " + txt;
logger.log(Level.INFO, logMessage);

If logger is not meeting your requirements, make it to do so by configuring it.
There are some widely used logging frameworks that are highly configurable and I doubt that they will not be able to do whatever you are doing with plain System.out.println
For example, check out very popular SLF4J and Logback as logging provider.
http://www.slf4j.org/
http://logback.qos.ch/

Liferay Log override

i want override the interface Log, because i use always this menssage:
private final static Log log = LogFactoryUtil.getLog(classess.class);
log.error("La cita " + cita.getIdCita() + " ha producido un excepcion en " + e.getClass() + " casuda por "
+ e.getCause() + ". Trace: " + e.getLocalizedMessage());
my idea is override log.error for get in for parameter the throwlable only and then print the message but i don't know how call to original error.

If I understood correctly, you want to introduce a new method (with 4 parameters) to the Log interface. This is completely discouraged, as your new interface would be utterly incompatible with the assumption that anybody else makes when using this interface (or when providing alternative implementations). You would basically maintain your own private fork of Liferay, largely incompatible with the rest of the world. And that only for a change in a lowly Log class.
Don't go there. It's not too bad to construct an error message like you do in the snippet that you include in your question.
If you have the same thing duplicated everywhere in your code and think it would be cleaner otherwise, encapsulate Liferay's logging within your own logging class and use that, delegating to Liferay's log in the end.
However, don't invest too much time in fancy logging. IMHO that problem has been tackled once and forever, and within an application context, you'd not be able to deliver significant enhancement to the logging world...

Splunk format key value pair

I want to change my logger statements using key/value pair in such a way to be able to use it in splunk search. How can I retain the text processOne completed in the output log. Please advice.
log.info("ProcessOne completed for Run id " + runId+ "...Time Taken(ms) + (System.currentTimeMillis() - tempTime));
I tried to change it in the way mentioned below, but I also want to add ProcessOne somewhere embedded inside this. How can I achieve it.
log.info("runId=%d, TimeTaken=%s", runId, (System.currentTimeMillis() - sTime_tds));

Why not just add a message key?
Message="processone completed"
Or break up further into process and status e.g.
Process=processone
Status=completed

Log4j not printing name before message

I have a log4j logger that I instantiate like this:
logger = Logger.getLogger("EQUIP(" + id + ")");
Doing so, when I call logger.info("message"), I should get an output like this (with some date formatting):
13/11/12 15:08:27 INFO: EQUIP(1): message
But I'm only getting:
13/11/12 15:08:27 INFO: message
I'm also printing logger.getName() to the console for debugging and it gives me back the correct "EQUIP(1)" name. This behaviour is happening in some cases in my program, where I have several loggers like this, but mostly in this specific class. I want to know if I'm doing something wrong, if this name should be only the class/package name, or if it can be anything (it works well in 80+% of my loggers). I need to print the ID of each equipment because I have several of them working simultaneous, and tracking them without this would be next to impossible.
How should I fix this, preferably without resourcing to changing all my log calls to include this prefix?

The output format depends on the pattern you've configured for the appender. If the pattern string includes %c then you'll get the logger name included, if it doesn't then you won't.
An alternative approach might be to use the mapped diagnostic context, which is designed to disambiguate between log output from different threads writing to the same logger.

Difference between logger.info and logger.debug

What is the difference between logger.debug and logger.info ?
When will logger.debug be printed?

I suggest you look at the article called "Short Introduction to log4j". It contains a short explanation of log levels and demonstrates how they can be used in practice. The basic idea of log levels is that you want to be able to configure how much detail the logs contain depending on the situation. For example, if you are trying to troubleshoot an issue, you would want the logs to be very verbose. In production, you might only want to see warnings and errors.
The log level for each component of your system is usually controlled through a parameter in a configuration file, so it's easy to change. Your code would contain various logging statements with different levels. When responding to an Exception, you might call Logger.error. If you want to print the value of a variable at any given point, you might call Logger.debug. This combination of a configurable logging level and logging statements within your program allow you full control over how your application will log its activity.
In the case of log4j at least, the ordering of log levels is:
DEBUG < INFO < WARN < ERROR < FATAL
Here is a short example from that article demonstrating how log levels work.
// get a logger instance named "com.foo"
Logger logger = Logger.getLogger("com.foo");
// Now set its level. Normally you do not need to set the
// level of a logger programmatically. This is usually done
// in configuration files.
logger.setLevel(Level.INFO);
Logger barlogger = Logger.getLogger("com.foo.Bar");
// This request is enabled, because WARN >= INFO.
logger.warn("Low fuel level.");
// This request is disabled, because DEBUG < INFO.
logger.debug("Starting search for nearest gas station.");
// The logger instance barlogger, named "com.foo.Bar",
// will inherit its level from the logger named
// "com.foo" Thus, the following request is enabled
// because INFO >= INFO.
barlogger.info("Located nearest gas station.");
// This request is disabled, because DEBUG < INFO.
barlogger.debug("Exiting gas station search");

This will depend on the logging configuration. The default value will depend on the framework being used. The idea is that later on by changing a configuration setting from INFO to DEBUG you will see a ton of more (or less if the other way around) lines printed without recompiling the whole application.
If you think which one to use then it boils down to thinking what you want to see on which level. For other levels for example in Log4J look at the API, http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html

Just a clarification about the set of all possible levels, that are:
ALL < TRACE < DEBUG < INFO < WARN < ERROR < FATAL < OFF

Basically it depends on how your loggers are configured. Typically you'd have debug output written out during development but turned off in production - or possibly have selected debug categories writing out while debugging a particular area.
The point of having different priorities is to allow you to turn up/down the level of detail on a particular component in a reasonably fine-grained way - and only needing to change the logging configuration (rather than code) to see the difference.

INFO is used to log the information your program is working as expected.
DEBUG is used to find the reason in case your program is not working as expected or an exception has occurred. it's in the interest of the developer.

This is a very old question, but i don't see my understanding here so I will add my 2 cents:
Every level corresponds/maps to a type of user:
debug : developer - manual debugging
trace : automated logging and step tracer - for 3rd level support
info : technician / support level 1 /2
warn : technician / user error : automated alert / support level 1
critical/fatal : depends on your setup - local IT

It depends on which level you selected in your log4j configuration file.
<Loggers>
<Root level="info">
...
If your level is "info" (by default), logger.debug(...) will not be printed in your console.
However, if your level is "debug", it will.
Depending on the criticality level of your code, you should use the most accurate level among the following ones :
ALL < TRACE < DEBUG < INFO < WARN < ERROR < FATAL < OFF

Info Messages are something which we would like to see even if the application is in best of state.
Debug messages are usually something that we would like to see while debugging some problem.

What is the difference between logger.debug and logger.info?
These are only some default level already defined. You can define your own levels if you like.
The purpose of those levels is to enable/disable one or more of them, without making any change in your code.
When logger.debug will be printed ??
When you have enabled the debug or any higher level in your configuration.