What is log4j?

As you can read in log4j homepage:

With log4j it is possible to enable logging at runtime without modifying the application binary. The log4j package is designed so that these statements can remain in shipped code without incurring a heavy performance cost. Logging behavior can be controlled by editing a configuration file, without touching the application binary.

So log4j is a Java API that let you insert in your code logging facilities that you can control using a specific configuration file: this way, for example, you can turn debugging info on or off simply touching the config file without looking throughout all your code looking for debug statements.
From a user perspective log4j is mainly composed by two objects: loggers and appenders. Let us have a look about these objects.

Logger

Here is the definitions from org.apache.log4j.Logger javadoc:

This is the central class in the log4j package. Most logging operations, except configuration, are done through this class.

As you can understand the logger is the programmer’s best friend: using the methods of Logger you really do logging.
There are mainly two ways you can get a Logger (both using static methods):

Logger log = Logger.getLogger(“myLogger”);

Loggers are hierarchically organized starting from the root logger that is the parent of all loggers. If you want to get an instance of the root logger you must use:

Logger rootLog = Logger.getRootLogger();

If you think that using

Logger log = Logger.getLogger(“root”);

is a good idea you are wrong: with these instructions you get a Logger called root that is the son of the real root logger.

Loggers give you different levels of logging:

• DEBUG: for simple debug informations.
• INFO: when you have to log something informative.
• WARN: when something not so normal is happening in your code.
• ERROR: use this to log error conditions in your code.
• FATAL: guess what?

Here you can find a simple java class that show you a Logger instantiation and usage.

Appender

The appender is somewhat hidden to programmer’s view: usually you will never use directly an appender (eg: you will never instantiate it) but it is used by the logger. Simply put the appender is the object that does the dirty work of outputting your own logs: you use a ConsoleAppender if you want your logs to appear on the console, you use a FileAppender if you want to write your logs on the disk etc. etc. You can have more than one appender for each logger so you can have output distributed on more places. Last but not least you can set a threshold for every appender making it possible to have different level of ‘debug information’ in different places.

It is configuration time!

An example is better than many words:

# Here is the definition of the rootLogger:
# it has to output all logs (DEBUG is the lowest level)
# it has to output using both ‘console’ and ‘file’ appender
log4j.rootLogger=DEBUG, console, file
# The appender called ‘console’ is of type ConsoleAppender
# This appender shows you all info for better debugging
# Its output is formatted using the inserted ConversionPattern
log4j.appender.console=org.apache.log4j.ConsoleAppender
log4j.appender.console.Threshold=DEBUG
log4j.appender.console.layout=org.apache.log4j.PatternLayout
log4j.appender.console.layout.ConversionPattern=%d %5p %c (%F:%L) – %m%n
# The appender called ‘file’ is of type FileAppender
# This appender shows you only messages ABOVE the INFO level
# It writes in file ‘test.log’ located in the directory
# stored in ‘user.home’ system property.
# Its output is formatted using the inserted ConversionPattern
log4j.appender.file=org.apache.log4j.FileAppender
log4j.appender.file.Threshold=INFO
log4j.appender.file.File=${user.home}/test.log
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%d %5p %c (%F:%L) – %m%n

Here you can find a simple archive containing a sources, executables and configuration files you can look at to better understand what I was saying.

See on ‘Appendix A’ about conversion patterns.

See on ‘Appendix B’ about variable expansion.

Now that you have a configuration file you have to tell log4j to use it and you have two possibilities: put it in the classpath calling it log4j.properties or use org.apache.log4j.PropertyConfigurator to load it through the configure() method as you can find in the archive.

Appendix A

Conversion pattern are listed in the javadoc of org.apache.log4j.PatternLayout and reported here for simplicity:

Appendix B

Here is what the org.apache.log4j.PropertyConfigurator says about variable expansion:

All option values admit variable substitution. The syntax of variable substitution is similar to that of Unix shells. The string between an opening “${” and closing “}” is interpreted as a key. The value of the substituted variable can be defined as a system property or in the configuration file itself. The value of the key is first searched in the system properties, and if not found there, it is then searched in the configuration file being parsed. The corresponding value replaces the ${variableName} sequence. For example, if java.home system property is set to /home/xyz, then every occurrence of the sequence ${java.home} will be interpreted as /home/xyz.

One of the nicest feature of org.apache.log4j.PropertyConfigurator I found is that you can use it to dinamically configure/reconfigure log4j. As stated in the javadoc the configure() method of this class can get a java.util.Properties as parameter: you can simply load a properties file that looks like the final result you want and then you can manipulate it runtime (as java.util.Properties) and pass it to PropertyConfigurator. With this method you can do whatever you want on log4j: create loggers/appenders runtime, change log level etc. etc.

Il problema

Il problema del QueueRequestor è che non ha un timeout dopo il quale ritorna in qualsiasi caso: se non si ottiene una risposta il QueueRequestor non fa procedere l’esecuzione e ciò non è bello.

La soluzione

Per la soluzione sono stato illuminato da questo post sui newsgroup: qui si afferma che il QueueRequestor è nient’altro che un wrapper di una serie di API pubbliche del package javax.jms.
Ecco una classe d’esempio che si interfaccia ad una coda JMS Tibco:
import javax.jms.*;
import java.io.Serializable;
import com.tibco.tibjms.TibjmsQueueConnectionFactory;

public class QueueRequestorImpl
{
private final static String QUEUE_PATH = “tcp://localhost:7222″;
private final static String QUEUE_NAME = “testQueue”;
private final static long QUEUE_TIMEOUT = 10000;

public static Object connect(Serializable request)
{
QueueConnection queueConnection = null;
QueueSession queueSession = null;
Queue queue = null;
ObjectMessage objmessage = null;

TemporaryQueue tempQueue = null;
QueueSender qSender = null;
QueueReceiver qReceiver = null;

try
{
QueueConnectionFactory queueConnectionFactory = null;
queueConnectionFactory = new TibjmsQueueConnectionFactory(QUEUE_PATH);
queueConnection = queueConnectionFactory.createQueueConnection();
queueSession = queueConnection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
queue = getQueue(QUEUE_NAME, queueSession);

tempQueue = queueSession.createTemporaryQueue();
qReceiver = queueSession.createReceiver(tempQueue);
qSender = queueSession.createSender(queue);
}
catch (Exception e)
{
return null;
}
finally
{
try
{
if (qReceiver!=null) qReceiver.close();
if (qSender!=null) qSender.close();
if (tempQueue!=null) tempQueue.delete();
if (queueConnection!=null) queueConnection.close();
}catch (Exception e){;}
}
try
{
objmessage = queueSession.createObjectMessage();
objmessage.setJMSReplyTo(tempQueue);
queueConnection.start();
objmessage.setObject(request);

long elapsedTime = System.currentTimeMillis();
qSender.send(objmessage);
Message response = qReceiver.receive(QUEUE_TIMEOUT);
elapsedTime = System.currentTimeMillis() – elapsedTime;
System.out.println(“QueueRequestorImpl Response Time: ” + elapsedTime);

if (response!=null)
System.out.println(“Message RECEIVED.”);
else
{
System.out.println(“Message TIMEOUT.”);
return null;
}

String sendIDString = objmessage.getJMSMessageID();
String respIDString = response.getJMSCorrelationID();
if (!sendIDString.equals(respIDString))
{
String msg = “‘”+sendIDString+”‘!=’”+respIDString+”‘”;
System.out.println(“JMSCorrelationID MISMATCH (“+msg+”).”);
return null;
}

return response;
}
catch (Exception e)
{
System.out.println(“JMSException ‘”+e.getMessage()+”‘”);
return null;
}
finally
{
try
{
if (qReceiver!=null) qReceiver.close();
if (qSender!=null) qSender.close();
if (tempQueue!=null) tempQueue.delete();
if (queueConnection!=null) queueConnection.close();
}
catch (Exception e){;}
}
}

public static Queue getQueue(String name, QueueSession session)
{
try
{
return session.createQueue(name);
}
catch(JMSException e)
{
throw new RuntimeException(“Session closed”);
}
}
}

Conclusione

Come si può vedere il problema è facilmente aggirabile, basta solo fare un po’ di googling e cercare nei javadoc.