David R. Heffelfinger

I'm proud to announce that the second edition of my JasperReports book, JasperReports 3.5 for Java Developers has been published.

The book has been updated to cover the latest features added to JasperReports since the first edition was published. Here is the table of contents:

Chapter 1: An Overview of JasperReports
Chapter 2: Adding Reporting Capabilities to our Java Applications
Chapter 3: Creating your First Report
Chapter 4: Creating Dynamic Reports from Databases
Chapter 5: Working with Other Datasources
Chapter 6: Report Layout and Design
Chapter 7: Adding Charts and Graphics to Reports
Chapter 8: Other JasperReports Features
Chapter 9: Exporting to Other Formats
Chapter 10: Graphical Report Design with iReport
Chapter 11: Integrating JasperReports with Other Frameworks

The full table of contents can be found here.

I also added JPA integration as part of the chapter on JasperReports integration with other frameworks.

An article based on the book can be found at the Packt Publishing web site, it covers the most common use for JasperReports, which is generating reports from database data.

Also, chapter 10, Graphical Report Design with iReport, is available for free, no registration required.

Both JDK 1.6 and GlassFish come bundled with Java DB, which is nothing but a rebranded Apache Derby RDBMS. If you have ever done anything with Derby, you know that a database can be created by simply by passing the create attribute with a value of true. For example, to create a database on a server called myserver.com, all that is needed is to use the following JDBC URL:

jdbc:derby://myserver.com:1527/mydb;user=foo;password=bar;create=true

The above JDBC URL will create a database called "mydb", and, in Derby/Java DB, the default schema matches the user name, so the above URL will create a schema called "foo" and set it as the default schema.

This is great in the sense that creating a database is very easy, but it is not so great in the sense that it allows anybody to create a database on the server and do whatever they want with it.

If this wasn't bad enough, by default passwords are ignored, therefore, with the default configuration in place, anybody can connect to the database as user "foo", for example, the following JDBC URL would connect you just fine:

 jdbc:derby://myserver.com:1527/mydb;user=foo;password=aaa

Notice that in this second JDBC URL, the password is different than the one we used when we created the database, it doesn't matter, in the default Derby configuration, the password is ignored, it is as if it didn't exist, therefore this URL would allow us to log in just fine.

Standalone Derby / Java DB only listens for connections from localhost, so in this case the default behavior is not too bad (there is still some security risk in a server with multiple users, however random people cannot connect through the network and create databases/log in to a database willy nilly).

However, GlassFish comes bundled with Java DB/Derby. When starting the database through GlassFish's asadmin utility:

asadmin start-database

The database by default listens accepts network connections. Unfortunately all other (lack of) security defaults stay in place, therefore with GlassFish's JavaDB's default configuration, random Joe's out there can connect to our databases without using a password, and can also create their own databases. This is a major security hole.

Luckily, Java DB/Derby can be easily configured to require valid user credentials, it is unfortunate that it is not configured this way by default. There are various ways to configure authentication in Derby/Java DB, it can be "hooked up" to an LDAP server, additionally, custom code can be written to handle authentication, and finally, a property file can be written set up authentication. The Derby Developer's Guide has all the details, in this entry, I'll just explain the simplest way, in case you are panicking because I just made you realized your database is exposed to the world.

The property file to create to enable authentication has to be called derby.properties it should look something like this:

derby.connection.requireAuthentication=true
derby.authentication.provider=BUILTIN

# Users definition
derby.user.someusername=password1
derby.user.john=doe

derby.connection.requireAuthentication=true tells Derby/Java DB that authentication is required.

derby.authentication.provider=BUILTIN sets up Derby to use its internal, built-in authentication mechanism.

After setting the above two properties, we need to add some users, they are added as shown in the above sample derby.properties file, properties preceeded by "derby.user." are understood to be users, the user name is the string immediately following "derby.user.", and the password is the value to the right of the equal sign. For example, if we wanted to add another user with a username of "joe", and a password of "secret", we would add the following line to derby.properties:

derby.user.joe=secret

Once we have created this file, we need to put it in $DERBY_HOME/bin if we are using the standalone Java DB/Derby or the Java DB version that is bundled with JDK 1.6. Java DB is placed under $JAVA_HOME/db in in Linux and under C:\Program Files\Sun\JavaDB in Windows.

If we are using the Java DB version that is included with GlassFish, then the derby.properties file needs to be placed under $GLASSFISH_HOME/databases, where $GLASSFISH_HOME is the directory where GlassFish is installed.

After copying the file to the appropriate location, the Java DB/Derby needs to be restarted for the changes to take effect.

Like I mentioned in my last post, I've been reading about Groovy lately. I'm finding Groovy very useful to automate small tedious tasks that I have to do in a regular basis.

For example, many times I have to zip up a directory, but there are some files or subdirectories I want to leave out. What I usually did was I would zip up the whole directory, then manually delete whatever I didn't want in the zip file. Alternatively, I would try to do it from the Linux command line, but I invariably would forget the syntax to do it, this would happen so often that I wrote a blog post explaining how to do it primarily so that I could refer to it myself.

ANT has a zip core task that can easily exclude files or directories from the resulting zip file, through Groovy's AntBuilder class, it is trivial to write Groovy scripts to invoke ANT tasks. It didn't take long to put two and two together, and write a simple Groovy script that would invoke the ANT zip task, specifying any unwanted files or directories.

Without further ado, here's the script:

#!/usr/bin/env groovy

def excludes="**/*.swp, somefile.txt, somedir/**"

def ant = new AntBuilder()

println "args = ${args}"

if (args.length > 0) {
 if (args[0].endsWith("/") || args[0].endsWith("\\")) {
    args[0] = args[0].substring(0, args[0].length() -1)
  }
  ant.zip(baseDir:args[0], destFile:args[0] + ".zip", excludes:excludes,
    update:true)
}
else {
  println "usage: ZipDir.groovy [dirName]"

}

Simply edit the value of the excludes variable to contain any valid comma-separated ANT patterns matching the files or directories you want to exclude from the zip file. Enjoy.