H2 database on GlassFish

Previously I’d written about running the H2 database within Tomcat.

Here’s a recipe for running under V3 of the Glassfish application server. I’ll create a datasource for the same “employee” database I used previously. I’m creating an in-memory embedded database, but you can connect to any other H2 configuration. Just change the URL format.

Installing the driver

H2 comes with a single JAR file containing both the database and the driver. Before starting up GlassFish, copy this h2.*.jar file into your domains/domain1/lib/ directory.

Now, start up the server: asadmin start-domain

Open up the admin console at http://localhost:4848

It’s possible to configure everything by editing your domain.xml file, or through the admin console GUI. For now, I’ll explain how to get things going through the GUI.

Create a connection pool

On the left side of the page there is a tree of tasks. Find Resources / JDBC / Connection Pools. Hit the “New…” button.

Set the pool name to be “empPool”, the resource type to be “javax.sql.DataSource”, and then fill in vendor name to be “H2″. Submit with the “Next” button.

On the next page, fill in the datasource class name as “org.h2.jdbcx.JdbcDataSource”. At the bottom of the page, edit the additional properties to have only the following, then hit the “Finished” button.

• user = sa
• password = ()
• url = jdbc:h2:mem:employee

Note that the password is set to just left and right parentheses. The admin GUI will interpret this as a blank string. If you tried to enter a blank password, the GUI would disregard your password field.

Now that the pool has been created, you’ll see “empPool” listed under the task tree. Click into this pool to review your setup. There is a “Ping” button on this page that will verify that you can connect to the database.

Set up a JNDI datasource

In the task tree, click into Resources / JDBC / JDBC Resources. Click “New…” to create a JNDI resource to the new connection pool.

The JNDI name should be “jdbc/empDS” and the pool name will be “empPool”. Submit with the “OK” button.

The GlassFish admin console can take care of everything. Just for fun, you can take a look at the “domain.xml” file to see how things are set up. Some environments work better by just deploying XML files.

Use your new datasource

At this point, you can retrieve the datasource "jdbc/empDS" from the InitialContext, and then get connections from the pool:

Context ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("jdbc/empDS");

 ...

 Connection conn = null;
 try {
     conn = ds.getConnection();
     ...
 } finally {
     if (conn!=null) { conn.close(); }
 }

The death of applets

Today there’s an article on Javalobby asking if, thanks to JavaFX, are Java Applets Making a Comeback? Clicking into the example applet documenting Olympic medals hangs Firefox on my Mac every time. This is my usual experience with JavaFX. So I guess the answer to the headline is “no”. JavaFX, despite being ambitious and well-intentioned, is putting some nails into the coffin.

The thing is, I’ve always been a big fan of applets. They can be a great platform for rich clients and for amateur game development. They’ve never really been a “failed” technology; they just didn’t develop the momentum that Flash enjoys. If you have a captive audience, such as with business applications, you can be reasonably sure that all users have Java installed, go ahead and develop as an applet. Wanna write some toys? Give Slick or PulpCore a try.

In the long term though, I’d say that applets are doomed. Not because of the initial start-up time (which isn’t so bad) or the lower installation base (which is easily manageable) or massively bloated graphics libraries (just avoid). Applets are doomed because they’ll never run on iPhones or Android devices.

The big future for client development will be on mobile devices, so the most important platform is going to be the one that runs on smart phones and pads and netbooks as well as conventional desktops. The only horse to bet on is certainly HTML5.

The next question is what kind of development platform will emerge on top of HTML5. Much of Flash’s success is due to the tools that let graphics folks become productive application developers. Some of us will try crafting apps with just text editors, but that definitely won’t be sufficient to supply all the new devices.