Tuesday, 26 August 2008

AmbiguousTableNameException in dbUnit

There is plenty of documentation on AmbiguousTableNameException in dbunit but I was unable to find a clear example showing the problem and the solution.

We have an application that needs to work on Oracle & SQLServer. The integration tests make extensive use of dbunits dataset classes to populate test databases. The tests clear out various tables & populate the tables as required. Previous to me being involved there would be only one database that had to be populated for use and cleaned out to run the tests. I found this a pain so I created a test database for the integration test use only.

SQL Server continued to work fine however when running the Oracle tests I got lots of AmbiguousTableNameExceptions being thrown. It took me a good while to make the connection as to the cause despite it being written in black & white.

Our code was creating the DatabaseConnection as follows:
DataSource ds = (DataSource) applicationContext.getBean(getDataSourceName());
DatabaseConnection mDbConnection = new DatabaseConnection(getConnection(ds));

Logically this should be absolutely fine. First off it all worked before. The Datasource fully describes the connection. In the debugger I could see the username, password and connection url. Accessing the database from the command line using the same parameters all looked cool. Upgrading to dbunit 2.2 proved fruitless.

So why would the connection come up with an AmbiguousTableNameException when that user has no privileges to see any other schema? The long answer to that defeats me.
However as I said the solution is there on the dbunit website.

Despite the fact that the connection has everything defined you still need to tell the DatabaseConnection object the schema name. In the constructor pass in the Schema name and all will be fine.


DatabaseConnection mDatabaseConnection = new DatabaseConnection(connection, getSchemaName());

This all appears to be a bug in dbunit and potentially a security flaw as it implies a connection with limited access can see other schemas.


Thursday, 21 August 2008

jar search tool

How often do you want to search a directory structure to see which jar a particular class is in.

I always end up doing the following:

list=`find . -name "*jar"`
for file in $list
do
echo $file
jar tvf $file grep Somepattern
done


I have done this long hand so many times that I have decided to script it.
Use this script jar_search like this.
jar_search ObjectPool
or
jar_search ObjectPool comm

The second parameter is optional and allows you to restrict what jars you will search through.

Here is the jar_search script:

#
# search a list of jar files for a pattern
# the jar pattern is optional
# By Bill Comer, August 2008
#

if [ $# -lt 1 ]
then
echo "Usage: jar_search [searchPattern] [jarPattern]"
exit -1
fi

searchPattern=$1
jarpattern=$2

list=`find . -name "*$jarpattern*.jar"`

for file in $list
do
found=`jar tvf $file | grep $searchPattern`
if [ ! -z "$found" ]
then
echo $file
echo $found
fi
done

Tuesday, 19 August 2008

Understanding Kaminsky's DNS Bug

See the linux journal for a very good explanation

If you are impatient or do not want to read the explanation
just go to doxpara.com and select the 'Check My DNS' button.

Friday, 15 August 2008

importing oracle dumps using imp or impdp

Using Oracle Enterprise Manager I was trying to import a DMP file into an oracle database & I got the error:
Import Submit Failed
There is a problem reading from the import files: ORA-39143: dump file "c:\temp\case9_0.DMP" may be an original export dump file .

There appears to be two import tools and Enterprise Manager only knows about 'impdp'. There is the old import tool 'imp' that is needed if the dump file was created using 'exp' as opposed to 'expdp' or via Enterprise Manager.

The solution.
Simply run:

imp user/password
where user & password are for the user in the dump file and it will prompt you for all the answers.