How to write exception stack trace on a String

Sometimes, we have the necessity to transform the exception stack trace in a string (e.g. for using a log method whose parameter is a string).

This is the code I use:

StringWriter sw = new StringWriter();

PrintWriter printWriter = new PrintWriter(sw);

ex.printStackTrace(printWriter);

log.write(sw.toString());

When == return true in String comparison?

In java String objects are pooled for performance issue. There are two different moments during which new strings are inserted into the pool. During compile time, literals are inserted into the pool so you could(but you must not) use == to compare two literals. At runtime, strings aren’t pull back from the pool… So e comparison between a literal value and a runtime value MUST use equals(). To decrease the memory footprint we can use the intern() method, which returns the string from the pool if it exists otherwise it will be inserted.

public class Test {
//to run with a a
public static void main(String[] args) throws Exception{

String literal1 = “a”;
System.out.println(“arg[0] = ” + args[0]);
System.out.println(“arg[1] = ” + args[1]);
String runtime1 = args[0];
String intern1 = args[1].intern(); //retrieved from pool
String literal2 = “a”;
System.out.println(“literal1==runtime1: “+(literal1==runtime1)); //false
System.out.println(“literal1==literal2: “+(literal1==literal2)); //true
System.out.println(“runtime1==intern1: “+(runtime1==intern1)); //false
System.out.println(“literal1==intern1: “+(literal1==intern1)); //true
System.out.println(“literal1.equals(runtime1): “+(literal1.equals(runtime1))); //true

}
}

http://forums.sun.com/thread.jspa?threadID=669414

Thread-safe singleton

It seems that the better way to implement a thread safe singleton in java is using an holder that solves the lazy initialization too:

public class ConfigurationRegistry
{
private ConfigurationRegistry()
{
}

public static ConfigurationRegistry getInstance()
{
//Holder.instance is lazy initialized the first time access…
return Holder.instance;
}

private static class Holder
{
//single line thread safe
static final ConfigurationRegistry instance = new ConfigurationRegistry();
}

}

Java and DST (daylight saving time)

Java uses time zone to mark a time that is relative to a DST period.
This is important in system integration. E.g. I have a system1 sending an xml file containing a date to another system2, these systems are located in the same country (having the same time zone).
Say that system2 parses the xml date ignoring its time zone, this could be a problem if the xml will be sent before DST and will be received during DST.
So: 14:00 +1 (before DST) is 14:00 +2 (during DST) and not 15:00 +1! If system2 parses the date without using the time zone it will remain 14:00 and will not became 15:00.

Instrumenting an ear with cobertura and ant

Using cobertura with ant is very simple, this is the build xml I’ve used:

################START build.xml################

<?xml version=”1.0″ encoding=”UTF-8″?>

<project name=”labs.cobertura.generic” basedir=”.”>

<description>
Generic file to instrument a an already compiled jar
precondition: having a jar normally compiled
usege: after the instrumentation, we have to insert the instrumentated jar,
containing the same classes as the original jar, into a location where it will be loaded.
(e.g. in the classpath startup of the application server)
author: Germano Giudici
</description>

<property file=”genericBuild.properties” />

<path id=”cobertura.classpath”>
<fileset dir=”${cobertura.dir}”>
<include name=”*.jar” />
</fileset>
</path>

<taskdef classpathref=”cobertura.classpath” resource=”tasks.properties” />

<target name=”instrument-jar”>
<mkdir dir=”${instrumented.dir}” />
<cobertura-instrument datafile=”${basedir}/cobertura.ser” todir=”${instrumented.dir}”>
<fileset dir=”.”>
<include name=”${original-jar-name}” />
</fileset>
</cobertura-instrument>
</target>

<target name=”coverage-reports”>
<mkdir dir=”${coverage.xml.dir}” />
<cobertura-report datafile=”${basedir}/cobertura.ser” srcdir=”${src.dir}” destdir=”${coverage.xml.dir}” format=”xml” />

<mkdir dir=”${coverage.html.dir}” />
<cobertura-report datafile=”${basedir}/cobertura.ser” destdir=”${coverage.html.dir}”>
<fileset dir=”${src.dir}”>
<include name=”**/*.java” />
</fileset>
</cobertura-report>
</target>

<target name=”clean”>
<delete dir=”${instrumented.dir}” />
<delete dir=”${reports.dir}” />
<delete file=”cobertura.log” />
<delete file=”cobertura.ser” />
<delete file=”cobertura.ser.lock” />
</target>
</project>

################END build.xml################

################START genericBuild.properties################

# The path to cobertura.jar
cobertura.dir=../lib

# the path to the instrumented classes’ sources
src.dir=../src
instrumented.dir=instrumented
reports.dir=reports
coverage.xml.dir=${reports.dir}/cobertura-xml
coverage.html.dir=${reports.dir}/cobertura-html
# The name of the jar to be instrumented. It must reside in the same sirectory of this file
original-jar-name=mnp.ear

################END genericBuild.properties################

I’ve used this to instrument a jar inside an ear, deployed to weblogic 8.1.4.

For default cobertura writes all stats whenever the jvm ends… to semplify this task I’ve deployed a simple servlet containing this code:

String className = “net.sourceforge.cobertura.coveragedata.ProjectData”;
String methodName = “saveGlobalProjectData”;
Class saveClass = Class.forName(className);
java.lang.reflect.Method saveMethod = saveClass.getDeclaredMethod(methodName, new Class[0]);
saveMethod.invoke(null, new Object[0]);

So when I want to flush the statistics gained by cobertura, all I’ve to do is invoke that servlet.

It’s important to start weblogic (or even wathever other AS) with the cobertura.jar in the classpath.

The statistics flush whill generate a file called cobertura.sar in the domain’s directory, then you can use it to generate the report (with coverage-reports task ).

No more “Unknown source” on exception stacktraces with code compiled with ant

Add this to javac tag: <javac srcdir=”${my-source}” destdir=”${my-dest}/classes” debug=”true” debuglevel=”lines,vars,source”>

Remote debugging fitnesse fixture

When executing a test, the fitness server run a new jvm, so it’s necessary to add this line in the test page:

!define COMMAND_PATTERN {java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=<port> -cp %p %m}

for explanation

Add spring managed beans library dynamically into a context

Problem:

We want to section an application into small modules (packaged as jars). The most ones containing spring managed bean and one conteining the code for recover them.

Solution:

The core of the jar containing the code for beans recovering was this:

    public static Object getBean(String beanId, String beanFactoryName) {
        BeanFactoryLocator locator = getSingletonBeanFactoryLocator();
        BeanFactoryReference bf = locator.useBeanFactory(beanFactoryName);
        return bf.getFactory().getBean(beanId);
    }

    private static BeanFactoryLocator getSingletonBeanFactoryLocator(){
        String s = "beanFactory.xml";
        BeanFactoryLocator res = org.springframework.beans.factory.access.SingletonBeanFactoryLocator.getInstance(s);
        return res;
    }

The key is the use of the class SingletonBeanFactoryLocator. It arranges the content of all the files named “beanFactory.xml” loaded by the classloader, so present everywhere in the classpath’s root positions, in a single context. So adding seamlessly a new library containig spring managed beans to application context it’s simple: you have to create a jar including a beanFactory.xml in the default package… that’s all! The beans will be loaded automatically in the context using the SingletonBeanFactoryLocator methods.

Increase console output size in Intellij idea 8

I’ve found that in the eighth release of idea IDE, the “Limit Run/Debug Console Output” setting is gone so actually the only way for increasing the console output size is to set the idea.cycle.buffer.size value in idea.properties.

Printing sql statements using oracle jdbc driver features on jboss

I’m tring to print all the sql statements executed by oracle jdbc driver (ojdbc14.jar).

It seems that the logging is possible only with java.util.logging feature, i’ve followed this paper to set the logger, in particular:

i’ve added this jvm parameters to jboss java options:

-Doracle.jdbc.Trace=true
-Djava.util.logging.config.file=c:\myConfig.properties

##################myConfig.properties##################
.level=SEVERE
oracle.jdbc.level=INFO
oracle.jdbc.handlers=java.util.logging.FileHandler
java.util.logging.FileHandler.level=INFO
java.util.logging.FileHandler.pattern=c:/jdbc.log
java.util.logging.FileHandler.count=1
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter

furthermore i've used ojdbc14_g.jar library insted of ojbc14.jar.

With this configuration, it writes a jdbc.log file containing all the logs from ojdbc14_g.jar library.
The first problem I encountered is the duplication of log entries in the jboss server.log.
The second problem is that the generated logs don't contain the sql statements but other less important infos.

This last problem seems due to the library version less then 10.2.0.4.0

I'm going to try a different driver version...