Apache Ant and Embedded Derby
Embedded Derby is a bit tricky to use from within Apache Ant scripts. The reason is that the Embedded Derby driver must unlock the database before another process can safely access the same database. If the first process terminates before the second process starts, there is no problem: a stale database lock is simply ignored. But if you have an Ant script that first accesses the database via
I encountered this problem a few months ago, and found a nice solution here. Of all the stuff in that article, I only used the "StopDatabaseTask.java" code (without the "ArrayList subtasks" which seems to be a left-over from the original organ donor). This solved all my problems and worked perfectly fine with the built-in GlassFish "asant" which I used for my install scripts. It stopped working however when I tried the same thing in GlassFish v3, which doesn't have "asant", so I tried Apache Ant version 1.7.1 instead. Suddenly the
Here is what I did. I found that extending the core
<sql>
tasks, and then via some other task deploys an application in some other process (e.g. GlassFish) that accesses the same database, the deployment will fail because the Ant process is still active and hasn't relinquished the lock.I encountered this problem a few months ago, and found a nice solution here. Of all the stuff in that article, I only used the "StopDatabaseTask.java" code (without the "ArrayList subtasks" which seems to be a left-over from the original organ donor). This solved all my problems and worked perfectly fine with the built-in GlassFish "asant" which I used for my install scripts. It stopped working however when I tried the same thing in GlassFish v3, which doesn't have "asant", so I tried Apache Ant version 1.7.1 instead. Suddenly the
<taskdef>
for shutting down the embedded database stopped working. After scratching my head a lot, I realized that the cause was that Apache Ant classloading has been changed into something that ordinary mortals can no longer understand. So what to do? One concern is that I want the solution to be backwards compatible with Apache Ant version 1.6.5 also, since that's the base version for GlassFish "asant".Here is what I did. I found that extending the core
<sql>
task into a custom version for Embedded Derby could be done in a way that works in both Apache Ant 1.6.5 and 1.7.1. The <taskdef>
code is shown below.
import java.sql.SQLException;This works exactly like the core
import org.apache.tools.ant.taskdefs.SQLExec;
import org.apache.tools.ant.BuildException;
public class SQLDerbyTask extends SQLExec {
private boolean create;
public boolean getCreate() { return create; }
public void setCreate(boolean x) { create = x; }
public void execute() throws BuildException {
String url = getUrl();
if (create) {
setUrl(url+ ";create=true");
}
try {
super.execute();
} finally {
setUrl(url+ ";shutdown=true");
try {
getConnection();
} catch (BuildException e) {
Throwable t = e.getException();
if (t instanceof SQLException) {
SQLException x = (SQLException) t;
if ("08006".equals(x.getSQLState()) && 45000 == x.getErrorCode()) {
System.err.println("Embedded database shut down");
return;
}
}
throw e;
}
}
}
}
<sql>
task, except that it also shuts down the Derby database after executing the SQL statements. And as can be seen, I have added a "create
" property because I needed it. Other Derby properties like "createFrom
" and "restoreFrom
" can be added in the same way.
GlassFish on my mobile phone
Visual proof:
Booting GlassFish v2.1.1 takes almost 10 minutes on my Linux-powered Nokia N900 smartphone, but that's not too bad considering it takes around 15 seconds on my 2.8 GHz Quad-Core Phenom-II machine. I haven't tried doing anything serious yet on the phone, and I don't know if I will spend any more effort on this. The only point of this exercise was to demonstrate the following three things:
Since Nokia N900 doesn't yet come with any "official" Java engine, I had to install a third-party Java. I just followed the instructions here to install OpenJDK. Many thanks to the Linux and GNU communities, and to Sun/Oracle, for providing all this software for free. Without free software we would all be stuck in the 1970s...
Installing GlassFish v2.1.1 directly from the jar file didn't work, I got some strange "No space left on device" error, despite having lots of space. So I did a fresh run of the installer on another Linux computer and then copied everything to the N900 system before doing the "setup.xml" and "start-domain" steps. Later on I realized that the v2.1.1 installer tries to start a Swing application in order to present the Sun License. Perhaps that's why it didn't work, because the Cambridge Software Labs OpenJDK for N900 doesn't support Swing. Anyway, running the installer on another machine and then copying the files to the N900 worked perfectly fine.

Booting GlassFish v2.1.1 takes almost 10 minutes on my Linux-powered Nokia N900 smartphone, but that's not too bad considering it takes around 15 seconds on my 2.8 GHz Quad-Core Phenom-II machine. I haven't tried doing anything serious yet on the phone, and I don't know if I will spend any more effort on this. The only point of this exercise was to demonstrate the following three things:
- The amazing computing power of today's smartphones
- The manifest superiority of the Linux operating system over all proprietary operating systems
- Payoff for the promise made by Java: "compile once, run anywhere"
Since Nokia N900 doesn't yet come with any "official" Java engine, I had to install a third-party Java. I just followed the instructions here to install OpenJDK. Many thanks to the Linux and GNU communities, and to Sun/Oracle, for providing all this software for free. Without free software we would all be stuck in the 1970s...
Installing GlassFish v2.1.1 directly from the jar file didn't work, I got some strange "No space left on device" error, despite having lots of space. So I did a fresh run of the installer on another Linux computer and then copied everything to the N900 system before doing the "setup.xml" and "start-domain" steps. Later on I realized that the v2.1.1 installer tries to start a Swing application in order to present the Sun License. Perhaps that's why it didn't work, because the Cambridge Software Labs OpenJDK for N900 doesn't support Swing. Anyway, running the installer on another machine and then copying the files to the N900 worked perfectly fine.