Category: Java

File this under argh!

We use the Jakrata Commons FileUpload to manage J2EE’s weakest link – file uploads.
So naturally, like an narrow-minded developer I test the functionality with Firefox and voila, the upload works. Wrong, and in a beautiful fashion it is the client who finds this out. It appears that Internet Explorer provides the path name for a file being uploaded differently than Firefox does. That is because when you ask FileUpload’s FileItem getName() method for the file’s name what you get is:
Firefox: filename.xyz
IE: C:\firstdir\another directory\more directory\you get the idea\filename.xyz

Beware!

Upgraded to Eclipse 3.0 just so we can enjoy MyEclipse‘s nifty new trinkets (JavaScript code completion!!!).
Eclipse 3.0 failed to install on my machine for some bizarre reason but today I downloaded it again and used a different zip program to extract it and voila, it works. A nice plug-in for Eclipse 2.0 was Eclipse Tail but sadly it does not work with Eclipse 3.0.
A short search dug up an alternative – LogWatcher. Works the same and allows you to follow the long traces and output from Tomcat or any other application server.

Supposed you just executed a database call using JDBC and the results were stored in a ResultSet object called rs. Then, you would expect the following to work if you test whether you returned a null value:


if (rs.getString("field") == null) {
// do something
}


You would be wrong.
Instead, JDBC offers the oh so intuitive wasNull() method:

String val = rs.getString("field");
if (rs.wasNull())
{
// do something
}

The logic behind this is that the ResultSet object is not pre-fetched and hence we can not test for its value before JDBC actually retrieved the value. Am I right?…

This is based on a posting to the SQL Server 2000 JDBC newsgroup.