Oli's Blog

Most changes of PatternTesting are under the hood: switch to Java 7, switch to Log4J-2 as logging framework and better exception handling in FileTester - if a file cannot be found, it is checked if it can be a case sensitive issue. This happens often if the build runs on a Linux server with case sensitive filenames.

A bigger change was the implementation of feature request 49. You will now be warned if you forget a commit after an database insert or update (see also blog entry from September).

Another change was the split of the ClasspathMonitor into ClasspathMonitor and ResourcepathMonitor. For more info about the ClasspathMonitor see the blog of August 2009.

If you want to save something in a database with pure JDBC you would normally

1. take a connection,
2. create a statement with it,
3. execute the statement and
4. close the connection.

Have I something forgotten? Don't know - so lets try it. Point 1 could be done by asking the Driver class, a connection pool or another kind of provider:

Connection connection = connectionProvider.getConnection();

With this connection you can call a method which uses this connection to save e.g. an address:

private static void save(Address address,
        Connection connection) throws SQLException {
    PreparedStatement stmt = connection.prepareStatement(
            "INSERT INTO addressbook (email, name, "
            + "city) VALUES (?, ?, ?)");
    try {
        stmt.setString(1, address.getEmail());
        stmt.setString(2, address.getName());
        stmt.setString(3, address.getCity());
        int rc = stmt.executeUpdate();
        if (rc < 1) {
            throw new SQLWarning("cannot save " + address);
        }
    } finally {
        stmt.close();
    }
}

As last point you close the connection in the calling method:

connection.close();

Does it work? In most cases yes, because normally the auto-commit flag is on, if you get a connection. But what happens, if auto-commit is off?

Auto-Commit Off = Lost Data

If auto-commit for a connecion is off you must call excplicit the commit:

connection.commit();

If you don't do it your changes are lost (there are some exeptions from that rule - the Oracle DB does a commit before it closes the connection).

The problem with this "forgotten" commit is, that no warning or exceptions comes up and you do not notice the lost data. This makes it hard to find the error - especially if the auto-commit is off only in same special cases.

The PatternTesting Proxy-Driver

PatternTesting provides you a wrapper around the original driver which allows you to log SQL statements but which warns you also if you forgot the commit statement for a connection with auto-commit off:

1 entries were updated with 'INSERT INTO addressbook (email, name, city) VALUES ('ob@aosd.de', 'Oli B.', 'nowhere')' but not committed.

This is the message you will see in this case. You only have to change the JDBC-URL and put ":proxy" after the jdbc prefix:

DriverManager.getConnection("jdbc:proxy:hsqldb:mem:testdb")

This is the URL for an HSQL memory DB. For more information see the Wiki article about SQL Logging and Monitoring.

Happy Debugging...

Do you know that? You have to maintain some old programs and you are wondering what the hell is that piece of code doing. Why does it work? And where is the architecture of that damn software system you should adapt for the future?

Welcome to the world of software archaeology, also known as legacy code. The first law of software archaeology from Mitch Rosenberg (see Wikipedia) gives you good feeling about the trouble in digging in old rotten code:

Everything that is there is there for a reason, and there are 3 possible reasons:

1. It used to need to be there but no longer does
2. It never needed to be there and the person that wrote the code had no clue
3. It still needs to be there and YOU have no clue

The corollary to this "law" is that, until you know which was the reason, you should not modify the code (or data).

And if you would like to learn some ancient language of the beginning of the computer stone age watch this video:

PatternTesting 1.6 no longer supports Java 5 - you now need at least Java 6 if you want to use PatternTesting. On the other side the classloader of Tomcat 8 is now directy supported by the ClasspathMonitor.

Some deprecated classes and methods were removed now. And some tester were extended: the FileTester prints now the filename for files which differs (see feature request 47) and allows you to add a StringConverter as argument. This allows you e.g. to ignore white spaces or upper case letters.

The ClassTester checks now also static initializers to find dependency problems to other classes during the startup phase of a class.

If you override Object.equals(..) you should also override Object.hashCode(). So your unit test for your class may look like:

    MyClass one = new MyClass();
    MyClass anotherOne = new MyClass();
    assertEquals(one, anotherOne);
    assertEquals(one.hashCode(), another.hashCode();

But does your implementation returns false if the argument is null? Or is a.equals(b) the same as b.equals(a)?

To answer theses questions PatternTesting provides an ObjectTester class which checks that for you:

    MyClass one = new MyClass();
    MyClass anotherOne = new MyClass();
    ObjectTester.assertEquals(one, anotherOne);

But the ObjectTester can do much more for you: it can check all equals implementation of a package hierarchy:

    ObjectTester.assertEqualsOfPackage("java");

For each class in the java package which have overriden the equals method the ObjectTester creates two test objects with the default constructor (if it has one) to verify the implementation.

But stop - what is, if the default constructor creates two different objects which are not equals? E.g. the Date class does it! Then you can exclude classes from the check in different ways:

    ObjectTester.assertEqualsOfPackage("java",
             Pattern.compile("java.*\\.Date"));

Here a Java pattern (which is new in PatternTesting 1.5.1) is used to exclude the Date classes in java.util and java.sql from testing the equals and hashCode implementation.

In a similiar way you can test different properties of your class like Serializable or Comparable with the different XxxTester classes in patterntesting.runtime.junit - try it!

Happy Testing

One of the most exciting features of PatternTesting 1.5 is the chance to log and monitor SQL statements. This feature was introduced with 1.4.1 and is described in SQL Logging and Monitoring - all you have to do is to add patterntesting-rt.1.5.0.jar as library and to use

jdbc:proxy:hsqldb:mem:testdb

as JDBC URL for an in-memory DB (HSQL) - or any other valid JDBC URL, prefixed with "jdbc:proxy:...".

Another improvement of 1.5 is the better performance of the ClasspathMonitor. Especially for large classpathes with more than 20,000 classes it needed some minutes to dump the unused classes and other informations into several files. Now the different infos are collected and dumped much faster. And the ClasspathMonitor should work better now together with the classloader of WebSphere if you use the PatternTesting Agent as described in Enabling ClasspathMonitor in Websphere.

Manche JDBC-Treiber erlauben es, dass SQL-Statements mitprotokolliert werden können. Was aber, wenn dies der Treiber im Projekt nicht kann? Dann gibt es die Möglichkeit auf PatternTesting auszuweichen. Dort gibt es seit 1.4.1 die Möglichkeit, über eine spezielle Proxy-URL einen ProxyDriver anzusprechen, der u.a. die Protokollierung der SQL-Anweisungen übernimmt.

jdbc:proxy:hsqldb:mem:testdb

So sieht z.B. die Proxy-URL für eine HSQL-Datenbank aus. Der Unterschied zur normalen JDBC-URL von HSQL (jdbc:hsqldb:mem:testdb) ist nur der zusätzliche "...proxy:..."-Eintrag in der URL.

Damit die SQL-Anweisung auch tatsächlich im Log erscheinen, muss der Log-Level für patterntesting.runtime.monitor.db auf DEBUG gesetzt werden. Als weiteres Schmankerl kann man die Anzahl der offenen Connections per JMX überwachen.

Genaueres kann im PatternTesting-Wiki unter SQL Logging and Monitoring nachgelesen werden.

The generation of sequence diagrams was slightly improved although it is still marked as "experimental". One bigger news is the support of ProxyDriver as JDBC driver. This allows you to monitor the number of open connections if your configured JDBC URL starts with "jdbc:proxy:...".

A new version of PatternTesting is released. With this version it is possible to log method calls as sequence diagram (see Generation of Sequence Diagrams). This feature is still experimental so if you find a bug report or have feature request for it report it on the project page at SourceForget.



Other changes are more under hood. There is now a MapTester available which allows you to compare two maps. Or JSR 305 and the @NotNull annotation is supported.

Happy New Year with PatternTesting

Today v1.3.0 of PatternTesting was released. One of the highlights is the ConnectionMonitor, which allows you together with the ProxyConnection to monitor the open DB connections.

PatternTesting Check.CT can detect now problematic calls with undefined encoding which can be disabled by SuppressEncodingWarning. In PatternTesting Concurrent the patch of Patrick Linskey is included. For an overview of all changes take a look at the changes report.

Happy New Year with PatternTesting