Rather than re-invent the wheel, I did a quick search on google for a Java library to take care of the feed processing for me. Sure enough, Rome seemed to fit the bill.

Merrily testing away in my Eclipse workbench, I quickly wrote the code to generate my atom feed. All was good with the world. The planets may or may not have aligned. And then I came to run it through ant.

Unfortunately, that’s where the problems started…

BUILD FAILED
C:\testAnt.xml:6: java.lang.ExceptionInInitializerError
 at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:115)
 at org.apache.tools.ant.Task.perform(Task.java:348)
...
Caused by: java.lang.ExceptionInInitializerError
 at java.lang.J9VMInternals.initialize(J9VMInternals.java:222)
 at com.sun.syndication.io.SyndFeedInput.build(SyndFeedInput.java:110)
...
Caused by: java.lang.NullPointerException
 at java.util.Properties.load(Properties.java:267)
 at com.sun.syndication.io.impl.PropertiesLoader.<init>(PropertiesLoader.java:74)
 at com.sun.syndication.io.impl.PropertiesLoader.getPropertiesLoader(PropertiesLoader.java:46)
 at com.sun.syndication.io.impl.PluginManager.<init>(PluginManager.java:54)
 at com.sun.syndication.io.impl.PluginManager.<init>(PluginManager.java:46)
 at com.sun.syndication.feed.synd.impl.Converters.<init>(Converters.java:40)
 at com.sun.syndication.feed.synd.SyndFeedImpl.<clinit>(SyndFeedImpl.java:59)

Bugger.

A quick google only turns up 2 useful hits: here and here. Both links seem to suggest that Rome can run into problems with the way it loads its classes. After much hacking around, I found that a (somewhat hacky) way to solve this was by over-riding the Thread’s ClassLoader in my main class; e.g.

public class Test extends Task{

    public void execute(){

        ClassLoader cl = Test.class.getClassLoader();
        Thread.currentThread().setClassLoader(cl);

        // now do Rome stuff
        ...
    }
}

It’s not pretty, but it works. For now.

This means that to test your code, you need to configure the code lookup in your runtime workbench – a pain if you have multiple runtime workbenches, or frequently clear your runtime workbench metadata.

An alternative approach, which I use, is to disconnect the debugger from the runtime workbench and connect it in your base workbench. This post details how.

The first step is to find out what port your server’s debug process is listening on. The default for WebSphere Application Server is 7777, but this might change if you’ve either customised it or configured multiple server instances. An easy way to check is to select the “debug” view in your Eclipse runtime workbench.

Debug View

In this picture, you can see that my WAS instance is running on port 7778. Make a note of this number, then select (in this view) the server (either of the top 2 lines), and click the disconnect icon (the red ‘N’ with 2 blobs icon). This disconnects the runtime workbench’s debugger from the server, freeing up the server’s debug port for another application i.e. your base workbench.

New config

Next, we need to create a runtime configuration in the base workbench to connect to the server. Open the debug configurations dialog (Run->Debug Configurations), and select “Remote Java Application”, then click the new button. All you really need to change from the default settings are the name (if you want to be able to remember it) and the port (to the port you wrote down earlier). Here’s mine:

Settings

Finally, hit debug and away you go.

To invoke a target in a separate ant file, you would use this code in one of your main file’s targets (etc):

<ant antfile="secondFile.xml" target="targetInSecondFile" />

To create a checkbox in SWT, you actually create a Button:

Button checkbox = new Button(parentComponent, SWT.CHECK);

To get the value (checked or not), the boolean method:

checkbox.getSelection();

• Using utility class to check for empty or null String in Java

Problems solved

• NullPointerException during class loading in Rome

if(var != null && var.length() > 0)

There are slight variations. Some use

if(var != null && !var.equals(""))

They’re all there to achieve the same purpose: check whether a String is null or empty.

I’ve always thought “there really should be a utility for this”, but written the code anyway. Today, when faced with repeating this pattern about 10 times, I finally decided to go and check the Apache Commons Lang javadoc and see if there was such a method. Unsurprisingly, there is, in StringUtils.

There’s actually a few:

• isBlank(String)

• isEmpty(String)

• isNotBlank(String)

• isNotEmpty(String)

Very handy.

• db2jcc.jar
• db2jcc_license_cu.jar

on the classpath of the application. These can be found in the java/ sub-directory of the db2 install directory (Program Files/IBM/SQLLIB for me on Windows).

Connecting

The connection server string depends on whether you are using type2 or type4.

• Type 1: JDBC-ODBC Bridge
• Type 2: Native-API/partly Java driver
• Type 3: Net-protocol/all-Java driver
• Type 4: Native-protocol/all-Java driver

Source: http://www.javaworld.com/javaworld/jw-07-2000/jw-0707-jdbc.html

Type2:

jdbc:db2:database

Type4:

jdbc:db2//server[:port]/database

Sample code

Opens a connection, executes a query and then closes the connection.

/* Load the driver */
Class.forName("com.ibm.db2.jcc.DB2Driver").newInstance();

/* open the connection */
Connection conn = DriverManager.getConnection(url, user, password);

Statement st = conn.createStatement();

/* Execute a simple query to test the connection */
ResultSet rs = st.executeQuery("SELECT COUNT(*) FROM myTable");
rs.next();

/* Print the query results */
System.out.println(rs.getInt(1));

/* don't forget to close the connection */
conn.close();