Tuesday, September 29, 2009

Wednesday, September 9, 2009

Tips for dealing with DB2 database samples in your product

In trying to ship a sample of the ITM (IBM Tivoli Monitor) database utilized by our product, we stumbled upon the cross-platform restrictions of the backup/restore commands for DB2, which state:
The supported platforms for DB2 backup and restore operations can be grouped into one of three families:
  • Big-endian Linux® and UNIX®
  • Little-endian Linux and UNIX
  • Windows®
After hours of fiddling with DB2 manuals and succeeding partially in moving the data from an DB2 in AIX 64 bits to a Windows 32 bits machune, I eventually stumbled upon this great developerWorks article, fittingly titled: Using DB2 utilities to clone databases across different platforms.

Essentially it uses a combination of the “db2move” and “db2look” commands, like this:

Exporting the data

To export the contents of the database, change to the directory where the exported directory where the files should be written and run:
db2move WAREHOUS export -sn ITMUSER
db2look -d WAREHOUS -e -a -o db2look.sql
where WAREHOUS is the name of the database I was exporting and ITMUSER the schema for it.

Importing the data

Copy over the files to the target machine and change to the directory where the exported files are. Then run the command:
db2 “create db WAREHOUS”
db2 –tvf db2look.sql

db2move WAREHOUS import
where WAREHOUS is the name of the database you are importing.

You can use a different database name, but you need to edit the first line of the db2look.sql file to match the name.

Thursday, September 3, 2009

Unit testing tools, a minimalist toolset.

After wading through the sea of unit testing tools out there, here is a minimalist (and so far, sufficient) set of open-source tools for testing server-side centric Java code.

----

JUnit 4.x

That is almost a given, full integration with Eclipse and Ant, standard in the industry, etc, etc. JUnit 4.1 is the last release where I did some thorough investigation of any new function, though the just released JUnit 4.7 (Aug/4th) has some function I would like to explore.

----

DDTUnit (http://ddtunit.sourceforge.net/)

This is the best alternative for data-driven testing, where the test code is small but has to use different data inputs.

Side comment:This presentation cross-compares DDTUnit with other data-driven approaches:

Tip: The syntax for the test XML data can be a chore, but this Eclipse snippet (with instructions) can help:
http://sourcepatch.blogspot.com/2009/08/ddtunit-and-eclipse-snippets.html

----

JMock (http://www.jmock.org/)

This library allows you to pre-program objects in the JUnit testcase with the "right" responses to exercise the target code.

----

JMockit (https://jmockit.dev.java.net/)

This library is used to replace Java calls ordinarily not under your control with code under your control.

For instance, you can intercept a call to DriverManager.getConnection and return your own implementation of java.sql.Connection.

Tip 1: This library requires you to add -java.agent=build_dir/libraries/test/jmockit/jmockit.jar to the unit execution path.
Tip 2: Avoid it if you can, it makes tests slower and harder to follow. If you have another entry point to pass a JMock object, such as setter method, do it.



Links I have bookmarked about unit testing recently: http://delicious.com/nastacio/unit-testing

Monday, August 31, 2009

DDTUnit and Eclipse Snippets

One of the tedious aspects of using the excellent DDTUnit library is the creation of the Java class for the test case and the XML data sets. There is no nice Eclipse wizard to do that for you, but today I started to create a set of Eclipse snippets for it. My productivity went to the ditch for the first three hours, but it should pay off sometime between today and tomorrow.

I just select some complicated block of DDTUnit source code or XML on Eclipse, right-click it and choose "Add to snippets". I then replace some hard-coded values, such as the name of an input object, with a variable and save it.

Later, when I need a similar snippet, I just position the cursor where I need the new source code or XML, double-click the snippet from the toolbar, fill out any variables associated with the template (usually one or two) and goodbye round-trips to the DDTUnit reference guide.

image

The snippets library master: http://drop.io/dnastacio/asset/ddtunit-eclipse-snippets-xml

Code comments are for newbies

I am sure you have seen or participated in a debate about how much or how little comments one should put in his own code.

Now look at this pearl I found while writing a presentation about the excellent JMock library.

Just think of the possibilities in terms of team communication: “Jim, can you unlock ThatClassThatFixesThatBugWeDiscussedLastThursday.java?”

image

Thursday, July 30, 2009

Distributed Java code inspection

As a requirement of our current project, we wanted to establish a minimum criteria of code quality ahead of formal code inspections. No point in wasting valuable brain capacity at spotting simple problems such as using “==” instead of “equals” and so on.

Static code analysis is a good starting point, though it can be a bit intransigent about false-positives, where the developer had good cause to write code in a way that the rule developer could not have anticipated.

Being that our main development tool is Eclipse, this was the one criteria that made me give up on the excellent FindBugs, in that there was no way to mark up the source code to tell FindBugs to ignore the problem in future scans.

Enter the Eclipse built-in code analysis, which not only allows scanning source code, but also has a simple way of marking false-positives inside the source code using a Java comment, so that further scans will not flag the problem again.

Sharing a rule base

The first step in sharing a rule base is to create one, which can be done from the “Run –> Analysis…” menu.

Set the “Scope” to “Analyze selected projects”, without actually checking any project box. This will allow you to right-click any project and then run the analysis only on the selected project.

Under “Rules”, pick the ones you consider the most important. It took me a couple of scans on pre-existing code to weed out the faulty ones (there are a few) and the overly conservative ones. Once I was satisfied, I clicked on the “Export…” button to save it to a file I could share with my colleagues.

image

Importing a rule base

Starting from the “Run –> Analysis…” menu again, click on the “New launch configuration” button, give it a name. Again, set the “Scope” to “Analyze selected projects”, without actually checking any project box.

In the “Rules” tab, click on the “Import…” button and select the “.dat” file exported in the previous step, which is stored in a location shared with the entire team.

Scanning the code

Right-click a Java project and select “Analysis –> [Name of your launch configuration]”. In a few seconds, the results will be displayed in the “Analysis Results” view.

image

Right-clicking any of the individual results shows a menu with options for a “Quick Fix” (available for some rules) or the selection of “Ignore Result”. The latter option will add a Java comment next to the flagged line of code, instructing the analyzer to not flag the problem in future scans.

image

image

Monday, May 18, 2009

AspectJ for Java logging: suppressing System.out debugging calls - part 7

We have all been there, adding a few System.out calls here and there to our Java code during development to help debug something that defies (bad) logic.

It seems all too common to, ahem, leave some of those calls behind, which introduces several problems in a product. Don't we love to see the occasional "WE ARE HERE!!" graffiti in the server console, or a 50MB trace file that cannot be opened by any text editor?

One way to prevent this problem is to continuously demand that developers pay attention to it, either deleting the offending statements or converting them to a Logger.log call. That approach also has drawbacks in that mistakes are, well, mistakes. A complementary approach to pleading with developers is to intercept the requests to System.out and System.err and route the "println" commands to a trace call.

Here are the changes to the Logging serviceability aspect. I still want to find a way to use the name of method calling System.out.println in the trace calls, but for now, here are the interesting bits:

...

public aspect Logging pertypewithin((my..*) && !Exception+){

/**
* Trace handler for each type.
*/
private static Logger trace = Logger.getLogger("my.project" ) ;

private static TracePrintStream sysoutTrace = null;

...

/**
* After the initialization of all classes in this project.
*/
after(): dcofpClassInitializer() {
String classname = thisJoinPointStaticPart.getSourceLocation()
.getWithinType().getName();
classname = LoggingUtil.normalizeClassName(classname);
trace = Logger.getLogger(classname);
sysoutTrace = new TracePrintStream(trace, "System.out", System.out);
}

...

/**
* Replace calls to SystemOut with trace calls
*/
PrintStream around(): dcofpSystemOutPrintln() {
return sysoutTrace;
}

...

/**
* Inner class used to convert System.out.println calls to trace calls.
*/
public class TracePrintStream extends PrintStream {
...
public void println(String str) {
trace.logp(Level.FINER, trace.getName(), method, str);
}
...
}
}

Tuesday, May 12, 2009

Generated Java-XML bindings and external builders in Eclipse

Our project is using the Apache XMLBeans tool to bind XML schemas to Java code.

One possibility to deal with the bindings is to generate them on a local machine and check in the generated code. The drawback is that people maintaining the code need to deal with all sorts of file operations for things as simple as a namespace change. The Java bindings wiggles at the will of its source XSD file, so that checking it in is not far from checking in a generated JAR or WAR file.

The other possibility is to generate the code during build time, using the xmlbean ant task, which would be sort of annoying for developers using the Eclipse environment. Whenever the project was imported anew from the source control system, they would have to first invoke the generation target and then refresh their workspace.

It turns out Eclipse has a great solution for this, in the form of a project builder.


I created a new builder, which invoked the correct ant target every time a developer used "clean" or "build".

That was it for the easy part. The next trick was to make the Ant target as efficient as possible, since it would be impractical for developers to wait several seconds for the "xmlbean" task completion every time they did something as simple as updating an unrelated Java source file.

That is when the Ant conditional targets come in handy. It was only a matter of setting a property if the files had never been generated or if the source XSD file was updated after they had been generated.

<property name="xmlbean.javac.optimize" value="on" />
<property
name="xmlbean.verbose" value="false" />
<property
name="xmlbean.quiet" value="true" />
<property
name="design.info.schema" value="${dir.schema}/DesignInfo.xsd" />

...

<condition property="xmlbean.designinfo.updated">
<or>
<not>
<available
file="${dir.build.xml.classes}" />
</not>

<uptodate targetfile="${design.info.schema}">
<srcfiles
dir="${dir.build.xml.classes}" />
</uptodate>
</or>
</condition>

 

<target name="genxmlbeans.designinfo" if="xmlbean.designinfo.updated">

<xmlbean schema="${design.info.schema}"
classgendir="${dir.build.xml.classes}"
classpathref="class.path"
failonerror="true"
optimize="${xmlbean.javac.optimize}"
verbose="${xmlbean.verbose}"
quiet="${xmlbean.quiet}" />

</target>

Monday, May 4, 2009

DDTUnit snippet to represent a HashMap containing complex objects

As a big fan of DDTUnit for Java unit testing, this gets me every time. I often need a java.util.HashMap object with complex values. Here it is for posterity (and later lookup) :

    <obj id="masterResults" type="java.util.HashMap" 
hint="map" keytype="string" valuetype="com.company.project.LogFileResult">
<item>
        <key type="java.lang.String">
            data/com.com.company.project.custom/config/Lotus/Domino/nl/example.log
</key>
            <value type="com.company.project.LogFileResult" hint="call"
                   method="constructor">
</value>

        </item>
    </obj>






The Java code to retrieve it inside the DDTUnit fixture:







    HashMap masterResults = (HashMap) getObject("masterResults");

Wednesday, April 29, 2009

"Improving interface design" presentation

By the way of a colleague, a thought inspiring presentation on the creation of user interfaces.

This one quote stuck with me above everything else:

"I've been amazed at how often those outside the discipline of design assume that what designers do is decoration. Good design is problem solving."

Friday, April 10, 2009

AspectJ for Java logging: Serviceability without the clutter - part 6

Just realized I was missing the join point for constructors in the code. I also noticed the "getArgs" method in the "thisJoinPoint" object, which simplified the "methodError" point cut.

See the changes in red and the whole "Logging.aj" aspect as it stands today:

package my.project.aspects;

import java.util.logging.Level;
import java.util.logging.Logger;

/**
* Aspect for Java logging throughout the code base.
*/
public aspect Logging pertypewithin(my..* && !Exception+) {

    private static Logger trace = Logger.getLogger("trace.my.project");

   /*
     * Pointcuts
     */
   
 
/**
* Initialization of all classes in the project.
*/
pointcut classInitializer() :
staticinitialization(my.project..*) &&
!within(Logging);

    /**

     * Execution body for all methods.
     */
    pointcut method():
(
execution
(my.project..*.new(..)) ||
        execution(* my
.project..*.*(..))
)

  &&
!within(my.project.D.*)
&&
!within(Logging);

    /**
     * Exception handling blocks inside all methods.
     */
    pointcut methodError():
        handler(handler(Throwable+) &&
!handler(InterruptedException+) &&

        within(my.project..*.*) &&
        !within(my.project.D.*) &&
        !within(Logging);

    /*
     * Join points
     */

    /**
     * After the initialization for all classes in this project.
     */
after(): classInitializer() {
String classname = thisJoinPointStaticPart.getSourceLocation().getWithinType().getName();
trace = Logger.getLogger("trace." + classname);
}

    /**
     * Entry trace statements for all methods.
     */
    before(): method() {
        if (trace.isLoggable(Level.FINER)) {
            trace.entering(
thisJoinPointStaticPart.getSourceLocation().getWithinType().getName(),

                    thisJoinPointStaticPart.getSignature().toString(),
                    thisJoinPoint.getArgs());
        }
    }

    /**
     * Exit trace statements for all methods.
     */
    after() returning (Object result): method() {
        if (trace.isLoggable(Level.FINER)) {
            trace.exiting(
thisJoinPointStaticPart
.getSourceLocation().getWithinType().getName(),

                    thisJoinPointStaticPart.getSignature().toString(),
                    result);
        }
    }

    /**
     * Exception handling blocks inside all methods.
     */
    before(): methodError() {
        if (trace.isLoggable(Level.FINER)) {
Object target = thisJoinPoint.getArgs()[0];
            trace.logp(Level.SEVERE,
thisJoinPointStaticPart.getSourceLocation().getWithinType().getName(),
                    thisJoinPointStaticPart.getSignature().toLongString(),
                    "Caught exception: " + target.getClass().toString(),
(Throwable)target);
        }
    }
 
}

Tuesday, April 7, 2009

AspectJ for Java Logging: Individual tracing control per Java package - Part 5

In "AspectJ for Java logging: Serviceability without the clutter - part 2" I had some difficulty in assigning a different trace handler for each class, which severely limited the application of the "Logging" aspect on larger programs. After all, it does not make sense to enable verbose trace on method entry/exit for all modules when debugging a single module.

A few minutes ago, some more reading solved the problem: one can use the "pertypewithin" aspect declaration, like this:

public aspect Logging pertypewithin(my.project..* && !Exception+){

/**
* Trace handler for each type.
*/
private static Logger trace = null;

/**
* Initialization of all classes in the project.
*/
pointcut projectClassInitializer() :
staticinitialization(my.project..*) &&
!within(Logging);

/**
* After the initialization of all classes in this project.
*/
after(): projectClassInitializer() {
String classname = thisJoinPointStaticPart.getSourceLocation().getWithinType().getName();
trace = Logger.getLogger("trace." + classname);
}

...

}


Now, the pointcut "projectClassInitializer" will pick out the static declaration of all Java classes within the project. Exceptions declared in the project are left out, as I do not see usefulness in instrumenting such basic classes, but that is a matter of preference.



The "after" advice will guarantee that the "trace" handler is initialized at the end of the static initialization for each class, using a handle named "trace.<classname>".



With this arrangement, it is now possible to configure different tracing levels within the logging.properties file for your java application, setting a different level for an entire package or for a single class, like this:




handlers = java.util.logging.ConsoleHandler
#handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler

trace.my.level = INFO
trace.com.ibm.project.module1.level = INFO
trace.com.ibm.project.module2.level = FINEST
trace.com.ibm.project.module2.ClassA.level = FINER
...



-----

Friday, April 3, 2009

AspectJ for Java logging: Serviceability without the clutter - Instrumenting a 3rd party library - part 4

Another common serviceability problem while assembling libraries from multiple sources is that sometimes a reused library may use a difference serviceability framework, or even worse, not have any serviceability at all.

In the previous entries I covered techniques to instrument your own source code and source code from a different contributor. Now it is time to cover a technique to cover 3rd party libraries.

With AspectJ, this is a simple task accomplished with the AspectJ compiler: ajc. The compiler parameters are covered in the ajc page of the AspectJ developer's guide, but I suspect the majority of the people building Java code will resort to an Ant script. AspectJ has an Ant task called iajc, from where you can execute the same commands.

----

Compiling your aspects

The first step is, of course, to compile the serviceability aspects covered in the previous entries.

<iajc destdir="${dir.build.classes}" classpathref="class.path" deprecation="${javac.deprecation}">
<sourceroots>
<pathelement location="${dir.src}"/>
<pathelement location="${aspects.path}"/>
</sourceroots>
</iajc>




where "dir.src" is the directory where the project source code is located and "aspects.path" is the source directory where the aspects are located





----





Instrumenting a 3rd party library





The Ant taks has to be slightly modified to reflect a JAR file as the type of input and output, like this:








<iajc outJar="${dir.build.lib}/3rdparty.jar" classpathref="class.path" deprecation="${javac.deprecation}">
  <injars>
<pathelement location="${3rdparth.installdir}/libs/3rdparty.jar"/>
</injars>
<sourceroots>
<pathelement location="${aspects.path}"/>
</sourceroots>
</iajc>


----





And you are done! If both the JSR-47 and the Log4J aspects are in place, not only your new "3rdparty.jar" file will be instrumented with serviceability trace statements, it will also replace all extraneous Log4J calls with calls to their equivalent in JSR-47.





That is a very good result, considering that the resulting application assembled from multiple sources and libraries will benefit from these desirable serviceability traits:





  1. Consistent tracing, with trace entries for all the method entry and exit points and for all catch blocks


  2. Consistent trace control, with a single JSR-47 logging.properties file for all components


  3. Consistent output, with all modules directing their tracing output to the same file.


Monday, March 30, 2009

AspectJ Development Tools - Inline aspect visualization inside Eclipse

As I wrote about using AspectJ for serviceability instrumentation, I thought I would also spend some time publishing a couple of screenshots of a great addition to your Eclipse environment.

It is called AspectJ Development Tools, or AJDT, for short. AJDT adds a perspective and a handful of views that make it easy to visualize how the aspects are cross-cutting your code base.

Installation

Your first step is to visit the AJDT web site, go to the "Downloads" page and determine the right level of AJDT for your Eclipse environment. For those using any of the Rational Software Development v7.0 siblings, such as Rational Software Architect, you are looking into the 3.2 version.

The installation of the plugin follows the standard Eclipse "Help->Software Updates->Find and Install..." sequence, where you will be able to register the Eclipse update side for AJDT.

Converting a Java project into an AspectJ project

You will need to convert Java projects into AspectJ projects before you can use Eclipse to apply aspects to your Java code. The "conversion" is fairly benign and reversible, adding a couple of facets to the ".project" file.

An "AspectJ" sub-menu will be displayed whenever you right-click any Java project, with a single and unmistakable option named "Convert to AspectJ Project". After the conversion, other options become available, including the action to undo the conversion.

Aspect visualization embedded into Java code

The AJDT extensions will show markers to the left of Java source code,with the icons indicating the type of join point, such as "around", "before" and "after". Note that you can also display the "Cross References" view of the advices being applied to a particular point in the code.


Click on the thumbnail to see a larger image

Simultaneous Aspect visualization for multiple files

Using the Aspect Visualization perspective, you can have a broader view into how the aspects are crosscutting your projects.
Note how the screen is logically divided in three parts, with the package selection on the left, a graphical representation of the advices for each class in the middle section, and a selector for the aspects you want to browse.

What I like the best is that all screen elements are fully navigable, with double-clicks to the classes or advices in the graphical display taking you to their respective location in the Java source code.


Click on the thumbnail to see a larger image

Monday, March 16, 2009

AspectJ for Java logging: Serviceability without the clutter ("around" we go) - part 3

Whenever I reuse someone else's code at the source level, I often discover that it uses some different logging toolkit than what I am using.
Log4J seems to take the prize because a lot of developers used it before JSR-47 came out, and some **still** use Log4J in defiance of JSR-47's release.
JRAS, from older versions of WebSphere, also comes to mind.

At any rate, combining two different log toolkits produces some undesirable results, mostly (1) two different configuration steps and (2) two different file outputs. You can add a new handler to Log4J to redirect its calls to solve problem "2", but "1" is still there rearing its ugly head.

AspectJ allows one to replace calls to a given method with different calls. You got it, how about an Aspect that replaces all Log4J calls with JSR-47 calls?

The alternative? Ripping through every single method in the second code-base to replace Log4J calls with JSR-47 calls, but it is very likely that the original code owner will not support your forked code-base. Yes, I don't like it either, and that is why I wrote this other aspect for a recent project.

There are ways of applying this technique to an existing JAR file if you are reusing libraries instead of source code. Theme for the next posting.

----
package my.project;

import java.util.logging.Level;
import java.util.logging.Logger;

/**
* Aspect used to wrap Log4J to ensure consistent logging throughout the entire project.
*
* @author Denilson Nastacio
*/
public aspect Log4J {

private static final Logger trace = Logger.getLogger("trace.my.project");

/*
* Pointcuts
*/

/**
* Pointcut for all log4j calls within the target module
*/
pointcut log4jCalls():
target(org.apache.commons.logging.Log) &&
within(my.someone.else.code*.*);

/**
* Pointcuts for isInfoEnabled calls.
*/
pointcut log4jIsInfoEnabled():
log4jCalls() &&
call(boolean isInfoEnabled());

/**
* Pointcuts for isTraceEnabled calls.
*/
pointcut log4jIsTraceEnabled():
log4jCalls() &&
call(boolean isTraceEnabled());

/**
* Pointcuts for isDebugEnabled calls.
*/
pointcut log4jIsDebugEnabled():
log4jCalls() &&
call(boolean isDebugEnabled());

/**
* Pointcuts for isWarnEnabled calls.
*/
pointcut log4jIsWarnEnabled():
log4jCalls() &&
call(boolean isWarnEnabled());

/**
* Pointcuts for isErrorEnabled calls.
*/
pointcut log4jIsErrorEnabled():
log4jCalls() &&
call(boolean isErrorEnabled());

/**
* Pointcuts for isFatalEnabled calls.
*/
pointcut log4jIsFatalEnabled():
log4jCalls() &&
call(boolean isFatalEnabled());

/**
* Pointcuts for info calls.
*/
pointcut log4jInfo(Object o):
log4jCalls() &&
args(o) &&
call(void info(Object));
pointcut log4jInfoEx(Object o, Throwable ex):
log4jCalls() &&
args(o,ex) &&
call(void info(Object,Throwable));

/**
* Pointcuts for trace calls.
*/
pointcut log4jTrace(Object o):
log4jCalls() &&
args(o) &&
call(void trace(Object));
pointcut log4jTraceEx(Object o, Throwable ex):
log4jCalls() &&
args(o,ex) &&
call(void trace(Object,Throwable));

/**
* Pointcuts for debug calls.
*/
pointcut log4jDebug(Object o):
log4jCalls() &&
args(o) &&
call(void debug(Object));
pointcut log4jDebugEx(Object o, Throwable ex):
log4jCalls() &&
args(o,ex) &&
call(void debug(Object,Throwable));

/**
* Pointcuts for warn calls.
*/
pointcut log4jWarn(Object o):
log4jCalls() &&
args(o) &&
call(void warn(Object));
pointcut log4jWarnEx(Object o, Throwable ex):
log4jCalls() &&
args(o,ex) &&
call(void warn(Object,Throwable));

/**
* Pointcuts for error calls.
*/
pointcut log4jError(Object o):
log4jCalls() &&
args(o) &&
call(void error(Object));
pointcut log4jErrorEx(Object o, Throwable ex):
log4jCalls() &&
args(o,ex) &&
call(void error(Object,Throwable));

/**
* Pointcuts for fatal calls.
*/
pointcut log4jFatal(Object o):
log4jCalls() &&
args(o) &&
call(void fatal(Object));
pointcut log4jFatalEx(Object o, Throwable ex):
log4jCalls() &&
args(o,ex) &&
call(void fatal(Object,Throwable));

/*
* Join points
*/

/**
* Replace calls to Log.isInfoEnabled
*/
boolean around(): log4jIsInfoEnabled() {
if (trace.isLoggable(Level.INFO)) {
return true;
} else {
return false;
}
}

/**
* Replace calls to Log.isTraceEnabled
*/
boolean around(): log4jIsTraceEnabled() {
if (trace.isLoggable(Level.FINER)) {
return true;
} else {
return false;
}
}

/**
* Replace calls to Log.isDebugEnabled
*/
boolean around(): log4jIsDebugEnabled() {
if (trace.isLoggable(Level.FINEST)) {
return true;
} else {
return false;
}
}

/**
* Replace calls to Log.isWarnEnabled
*/
boolean around(): log4jIsWarnEnabled() {
if (trace.isLoggable(Level.WARNING)) {
return true;
} else {
return false;
}
}

/**
* Replace calls to Log.isErrorEnabled
*/
boolean around(): log4jIsErrorEnabled() || log4jIsFatalEnabled() {
if (trace.isLoggable(Level.SEVERE)) {
return true;
} else {
return false;
}
}

/**
* Replace calls to Log.info
*/
void around(Object o): log4jInfo(o) {
if ("".equals(o) == false) {
trace.logp(Level.INFO,
thisJoinPointStaticPart.getSourceLocation().getWithinType().getName(),
thisJoinPointStaticPart.getSourceLocation().toString(),
o.toString());
}
}
void around(Object o, Throwable ex): log4jInfoEx(o, ex) {
trace.logp(Level.INFO,
thisJoinPointStaticPart.getSourceLocation().getWithinType().getName(),
thisJoinPointStaticPart.getSourceLocation().toString(),
o.toString(), ex);
}

/**
* Replace calls to Log.trace
*/
void around(Object o): log4jTrace(o) {
trace.logp(Level.FINER,
thisJoinPointStaticPart.getSourceLocation().getWithinType().getName(),
thisJoinPointStaticPart.getSourceLocation().toString(),
o.toString());
}
void around(Object o, Throwable ex): log4jTraceEx(o, ex) {
trace.logp(Level.FINER,
thisJoinPointStaticPart.getSourceLocation().getWithinType().getName(),
thisJoinPointStaticPart.getSourceLocation().toString(),
o.toString(), ex);
}

/**
* Replace calls to Log.debug
*/
void around(Object o): log4jDebug(o) {
trace.logp(Level.FINEST,
thisJoinPointStaticPart.getSourceLocation().getWithinType().getName(),
thisJoinPointStaticPart.getSourceLocation().toString(),
o.toString());
}
void around(Object o, Throwable ex): log4jDebugEx(o, ex) {
trace.logp(Level.FINEST,
thisJoinPointStaticPart.getSourceLocation().getWithinType().getName(),
thisJoinPointStaticPart.getSourceLocation().toString(),
o.toString(), ex);
}

/**
* Replace calls to Log.warn
*/
void around(Object o): log4jWarn(o) {
trace.logp(Level.WARNING,
thisJoinPointStaticPart.getSourceLocation().getWithinType().getName(),
thisJoinPointStaticPart.getSourceLocation().toString(),
o.toString());
}
void around(Object o, Throwable ex): log4jWarnEx(o, ex) {
trace.logp(Level.WARNING,
thisJoinPointStaticPart.getSourceLocation().getWithinType().getName(),
thisJoinPointStaticPart.getSourceLocation().toString(),
o.toString(), ex);
}

/**
* Replace calls to Log.error and Log.fatal
*/
void around(Object o): log4jError(o) ||
log4jFatal (o) {
trace.logp(Level.SEVERE,
thisJoinPointStaticPart.getSourceLocation().getWithinType().getName(),
thisJoinPointStaticPart.getSourceLocation().toString(),
o.toString());
}
void around(Object o, Throwable ex): log4jErrorEx(o, ex) ||
log4jFatalEx(o,ex) {
trace.logp(Level.SEVERE,
thisJoinPointStaticPart.getSourceLocation().getWithinType().getName(),
thisJoinPointStaticPart.getSourceLocation().toString(),
o.toString(), ex);
}

}

Friday, March 13, 2009

AspectJ for Java logging: Serviceability without the clutter - part 2


In the previous entry about an Aspect for Java logging, I forgot to add a higher-level picture of the end-results.

Let's say your Java project has 4 major packages:
  1. my.otherproject.A
  2. my.project.B
  3. my.project.B.parsers
  4. my.project.C

With the Java logging aspect added to the code base, you can invoke your program with the standard Java logging option:
java -Djava.util.logging.config.file=<logging.properties> application.class

where <logging.properties> is a standard Java logging configuration file.

You can read more about the structure of this file in the Java Logging Overview, but here is an example of what I use:

# "handlers" specifies a comma separated list of log Handler 
# classes. These handlers will be installed during VM startup.
# Note that these classes must be on the system classpath.
# By default we only configure a ConsoleHandler, which will only
# show messages at the INFO and above levels.
handlers = java.util.logging.ConsoleHandler

# To also add the FileHandler, use the following line instead.
#handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler

# Default global logging level.
# This specifies which kinds of events are logged across all loggers.
# For any given facility this global level
can be overriden by a facility
# specific level
.
# Note that the ConsoleHandler also has a separate level

# setting to limit messages printed to the console.
trace.my.level = INFO
trace.my.project.level = FINER

############################################################
# Handler specific properties.
# Describes specific configuration info for Handlers.
############################################################

# default file output is in user's home directory.
java.util.logging.FileHandler.pattern = project%u.%g.log
java.util.logging.FileHandler.limit = 5000000
java.util.logging.FileHandler.count = 5
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter
java.util.logging.FileHandler.level = FINEST
java.util.logging.FileHandler.append = false

# Limit the message that are printed on the console to INFO and above.
java.util.logging.ConsoleHandler.level = INFO
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter


-----





Since the Java logging handles are hierarchical, the declaration of "trace.my.level = INFO" sets the default to all packages, whereas the declaration "trace.my.project.level = FINER" entry sets a different tracing level for your instrumented classes under the "my.project" Java package.





Dealing with verbose classes





One can tweak the "method" join point to exclude verbose classes from the tracing aspect, along the lines of:





    pointcut method():


        execution(* my.project..*.*(..)) &&


        !within(my.project.D.*) &&


        !within(Logging) &&


        !within(excluded.class.1) &&


        !within(excluded.class.2) &&


        !within(excluded.class.n);


 





Dealing with methods inside loops






This point is a bit more complicated and I'll get to it in a different post.

Tuesday, March 10, 2009

Dealing with timestamps in BIRT reports

While trying to match date/time fields between a BIRT (Business Intelligence and Reporting Tools) report design file and a web service, I did not stumble upon any good tips on the BIRT Eclipse website, but eventually found this entry on the BIRT Exchange website: Convert String Date to Date Object in BIRT.

The example was not a perfect match for what I needed but threw me close enough to the solution.

The web service returns a long value corresponding to the time using the Java/C convention for milliseconds since Jan/1/1970 0:00:00 GMT”. Inside the BIRT data-set though, I could not find the “Timestamp” field available for other kinds of data-sources, such as the XML data-source. Returning a string representing the date and time is never a good strategy since it discards the time zone information.

The solution was to create a computed field with “Date Time” type, then use this expression derived from the article to convert the milliseconds value retrieved from the web service (originally named “Date”):

df = new Packages.java.util.Date();
df.setTime(row["Date"]);
df



image



image



The next step was to indicate the correct type for the new computed parameter “DateTime” in my chart:



image

Tuesday, March 3, 2009

AspectJ for Java logging: Serviceability without the clutter - part 1

I have grown fond of AspectJ in the past years, probably at the same rate I have grown tired of writing or referencing the same cross-cutting snippets of code all over the code-base of a project.

In the way of background, AspectJ is a Java extension for "Aspect Oriented Programming" (PDF download), or AOP for short.

You can read the entire background in the previous link, but in a nutshell, AOP allows you to abstract common code snippets (advices, in AspectJ lingo) that are executed on common points of the code-base (join points.)

As a concrete example, I'll reference an Aspect that I have been perfecting on my last three projects: adding debugging trace statements to the entry/exit of all methods in a project.

I won't lie to you, it is not a trivial technique and the average Java programmer who eventually inherits your code base will hate your guts.

Setup your environment

Using the Eclipse environment and the AJDT (AspectJ Development Tools) is almost mandatory when dealing with aspects in Java. If you already have one of the Rational Software Development Platform siblings installed on your machine, such as Rational Software Architect, you are in good shape too, just pay attention to their underlying Eclipse version in order to select the right level of AJDT.

Since this is not an Eclipse primer, I assume you know how to deal with installation of plugins from update sites.

Trace statements

If you want somewhat decent traceability, you should look into three types of statements:

Method entry:

    if (trace.isLoggable(Level.FINER)) {
        trace.entering(<CLASS_NAME>, <METHOD_NAME>, <args> ) ;
    }


Method exit:

    if (trace.isLoggable(Level.FINER)) {
        trace.exiting(<CLASS_NAME>, <METHOD_NAME>, <args> ) ;
    }


Exception handling:

    catch (<EXCEPTION_CLASS> e) {
        trace.logp(Level.SEVERE,
<CLASS_NAME>, <METHOD_NAME>,
                   "Caught exception: " + e.getClass().toString(),
                   e);
    }


The Logging aspect

This is also not a primer on AspectJ, so that I assume you know that aspects go inside an "Aspect" file sitting inside any regular folder corresponding to a Java package. Here is what I have for trace.


package my.project.aspects;

import java.util.logging.Level;
import java.util.logging.Logger;

/**
* Aspect for Java logging throughout the code base.
*/
public aspect Logging {

    private static Logger trace = Logger.getLogger("trace.my.project");

   /*
     * Pointcuts
     */
   
 
    /**
     * Execution body for all methods.
     */
    pointcut method():
        execution(* my.project..*.*(..)) &&
        !within(my.project.D.*) &&
        !within(Logging);

    /**
     * Exception handling blocks inside all methods.
     */
    pointcut methodError(Throwable t):
args(t) &&
        handler(Throwable+) &&
        within(my.project..*.*) &&
        !within(my.project.D.*) &&
        !within(Logging);

    /*
     * Join points
     */

    /**
     * Entry trace statements for all methods.
     */
    before(): method() {
        if (trace.isLoggable(Level.FINER)) {
            trace.entering(
thisJoinPointStaticPart.getSignature().getDeclaringTypeName(),

                    thisJoinPointStaticPart.getSignature().toString(),
                    thisJoinPoint.getArgs());
        }
    }

    /**
     * Exit trace statements for all methods.
     */
    after() returning (Object result): method() {
        if (trace.isLoggable(Level.FINER)) {
            trace.exiting(
thisJoinPointStaticPart
.getSignature().getDeclaringTypeName(),
                    thisJoinPointStaticPart.getSignature().toString(),
                    result);
        }
    }

    /**
     * Exception handling blocks inside all methods.
     */
    before(Throwable t): methodError(t) {
        if (trace.isLoggable(Level.SEVERE)) {
            trace.logp(Level.SEVERE,
thisJoinPointStaticPart.getSignature().getDeclaringTypeName(),
                    thisJoinPointStaticPart.getSignature().toLongString(),
                    "Caught exception: " + t.getClass().toString(),
t);
        }
    }
 
}







Advanced reading





In the way of advanced reading, one can browse through developerWorks excellent AOP@Work series.





I particularly like "Next Steps with Aspects" and "AOP Myths and Realities".

Thursday, January 22, 2009

Creating a splash screen effect with Dojo

Many professionally designed applications provide a splash screen while the main application loads in background, so that I thought I would learn how to do it using Dojo 1.2.

Starting from an external blog entry with a working example I had to spend a few extra minutes on the Dojo documentation to find the right fade-in call in Dojo 1.2, which turned out to be “dojo.anim”.

The final technique is summarized in this modified version of the original blog entry:

function show_main_gui() {
    dojo.byId(“splash”).style.display = “none”;
    dojo.anim(“real”, { opacity: 100 }, 100);
}
dojo.addOnLoad(show_main_gui);



<div id="splash" style="z-index: 100; width: 100%; position: absolute; top: 200px">
<div align="center">
<img src="images/throbber.gif" />
</div>
</div>



<div id="real" style="filter: progid:dximagetransform.microsoft.alpha(opacity=1); opacity: 0.01" dojotype="LayoutContainer">
...
</div>


The original entry also lists this nifty generator for the “loading” icon.

Monday, January 19, 2009

Getting your numbers straight when programming in Java

While going through a cursory code inspection, some common patterns emerged above the throng. A few of them tend to trick even the more experienced programmers, less on the account of their skill than on the account of being syntactically too small to spot:

Automatic type promotion

Programmers tend to rely on the compiler to automatically promote smaller types into larger types, which works well **during the assignment** from one to another. If you are multiplying two smaller types that may result in a number that needs a larger type to be represented, **there is no automatic type promotion**.

int appleValue= 55;
int appleCount = 2000 * 1000 * 1000;
long appleNetWorth …;
appleNetWorth = appleValue * appleCount; // WRONG RESULT, TYPE OVERFLOW!
appleNetWorth = (long) (appleValue * appleCount); // WRONG RESULT, TYPE OVERFLOW!
appleNetWorth = (long) appleValue * appleCount; // Nefariously correct!
long appleNetWorth = (long)appleValue * (long)appleCount; // Verbosely correct!

Use “Number.toString” to convert numbers to strings

Whether you should be always using java.text.NumberFormat depends on your particular purpose at the time, but otherwise use the static “toString” method for the corresponding numeric type. Avoid constructs like this:

String appleValueStr…;
appleValueStr = "" + appleValue; // BAD: It works...at a cost…
appleValueStr = Integer.toString(appleValue); // GOOD

This kind of construct has two obvious problems, the first being that I will be mad at you due to the second problem, which is the wasteful creation of an additional String to contain the result of the concatenation.

Avoid constructing Number instances.

Number is the base type for Integer, Long, Float, and other numeric types. Creating a new number using its constructor inhibits JRE optimizations where the most common numbers (-128 to 128) are cached.

Integer appleValueObject = ...;
appleValueObject = new Integer(appleValue); // BAD: Prevents memory optimization
appleValueObject = Integer.valueOf(appleValue); // GOOD: May save you some memory for small numbers

Monday, January 12, 2009

Configuring Windows Live Writer to post on IBM Communities

IBM Communities is an interesting experiment on bridging its internal networks of subject-matter experts and its external network of customers and partners (disclaimer, I am an IBM software engineer.)

As a heavy internal blogger sold on the concept of blogging as a personal empowerment tool over centrally controlled knowledge distribution, I was initially skeptical of the notion of corporate sponsored blogging, but I accepted the challenge of giving it a go for a a few months.

Enough with the philosophical observations, which I reserve for my other blog, the sourcepatch is about coding hacks and technical tips. In this entry I wanted to help people setup their favorite off-line editors to work with IBM Communities, starting first with Windows Live Writer (in fairness, employee-employeer loyalty and all that, WLW is a remarkable tool) .

Setup steps

  1. I started with the latest version: 14.0.8050.1202 en with the intention of pointing at my newly created blog, the Energy Scrolls, at https://www-951.ibm.com/blogs/energyscrolls.
  2. Select Blogs –> Add blog account…
  3. In the “What blog service do you use?”, select “Other blog service”
  4. In the next dialog, use “https://www-951.ibm.com/” for the Web address of your blog and provide your username and password, click on “Next”
    image
  5. In the “Select blog type” dialog, select “Atom Publishing Protocol” as the type of blog and use “https://www-951.ibm.com/blogs/api” as the service document URL, click on “Next”.
     image
  6. Select your blog for the account being created (you can create other accounts for eventual additional blogs) and click on “Next”.
    image
  7. I could not get it to detect the blog theme or upload images, but I pointed to the “Energy Scrolls – Media Entries” when prompted for a place to upload my files, then click on “Next”
  8. Just pick a nickname of your choice in the next panel and you are done.
    image

Two more disclaimers:

  1. When I post an entry and check the “View in browser after publishing”, the browser does not open the entry correctly as it does for posting to other blogging platforms.
  2. I could not get the Blogger and MetaWeblog APIs to work.

Now onto figuring out how to do the same with w.bloggar and ScribeFire.