Apache Shiro (formerly known as JSecurity and KI) is a security framework that handles authentication, authorization, enterprise session management and cryptography. With the move from sourceforge to Apache the GPL license turned into the Apache license. The current version is still 0.9 (still JSecurity), but you can build yourself a current version until the version is released. Shiro is NOT basd on JAAS.

Pre-Requirements for this tutorial:

• Netbeans (any newer version 6.5.1 + already installed)
• Maven (assuming most people dont use it yet)
• Shiro code base (via svn)
• Ubuntu (applies only to the installation of maven)

Installation of maven under Ubuntu:

• sudo apt-get install maven2 (will result in a substantial 130MB  download)
  

  Install maven

Download and building Shiro:

• svn it into a local folder of your choice (preferably called shiro) from apache.org with  svn co http://svn.apache.org/repos/asf/incubator/shiro/trunk/

   

  

  svn shiro

• Build it with mvn install (which downloads even more pom files and a build and test process that can take some minutes)
  

  Build Shiro with Maven

Create most simple java project

The shiro package you svn’ed earlier comes with a couple of samples, which really give you a good start, but it is always good to start from the scratch with virtually nothing. This simple application follows pretty much the quickstart.java sample from the Shiro team (link).

Create a new Java Application

Create new application

Add the Shiro (from the core folder that we maven’d), log4J and SLF4J library (from the samples folder)

Libraries

Import the packages

import org.apache.shiro.SecurityUtils;
import org.apache.shiro.authc.*;
import org.apache.shiro.mgt.DefaultSecurityManager;
import org.apache.shiro.realm.text.PropertiesRealm;
import org.apache.shiro.session.Session;
import org.apache.shiro.subject.Subject;

Create most basic functionality

 public static void main(String[] args) {

 DefaultSecurityManager securityManager = new DefaultSecurityManager();
 securityManager.setRealm(new PropertiesRealm());
 SecurityUtils.setSecurityManager( securityManager );

 Subject currentUser = SecurityUtils.getSubject();

 if ( !currentUser.isAuthenticated() ) {

 //UsernamePasswordToken token = new UsernamePasswordToken("jamesbond", "007" );
 UsernamePasswordToken token = new UsernamePasswordToken("lonestarr", "vespa" );

 token.setRememberMe(true);
 try {
 currentUser.login(token);
 } catch (UnknownAccountException uae) {
 System.out.println("There is no user with username of " + token.getPrincipal() );
 } catch ( IncorrectCredentialsException ice ) {
 System.out.println("Password for account " + token.getPrincipal() + " was incorrect!");
 } catch ( LockedAccountException lae ) {
 System.out.println("The account for username " + token.getPrincipal() + " is locked.  " +
 "Please contact your administrator to unlock it.");
 }
 // ... catch more exceptions here (maybe custom ones specific to your application?
 catch ( AuthenticationException ae ) {
 //unexpected condition?  error?
 }
 }
 System.out.println(" User [" + currentUser.getPrincipal() + "] logged in successfully.");

 //test a role:
 if ( currentUser.hasRole( "agent" ) ) {
 System.out.println("License to kill." );
 } else {
 System.out.println( "Sorry, Martini only." );
 }

 //test a typed permission (not instance-level)
 if ( currentUser.isPermitted( "gadgets:astonmartin" ) ) {
 System.out.println("Keys for your company car.");
 } else {
 System.out.println("Sorry, subway ticket only.");
 }

 //test a typed permission (not instance-level)
 if ( currentUser.isPermitted( "lightsaber:weild" ) ) {
 System.out.println("You may use a lightsaber ring.  Use it wisely.");
 } else {
 System.out.println("Sorry, lightsaber rings are for schwartz masters only.");
 }

 //all done - log out!
 currentUser.logout();

 System.exit(0);
 }

Remarks:

• We dont have a seurity realm, so the sample code play with the default user, password, roles that are part of the Shiro package in core/src/main/resources/org/apache/shiro/realm/text/default-shiro-users.properties

  ...
  # ------------------------------
  # Users and their assigned roles
  # ------------------------------
  # user 'root' with password 'secret' and the 'root' role
  user.root = secret,root
  # user 'guest' with the password 'guest' and the 'guest' role
  user.guest = guest,guest
  # user 'presidentskroob' with password '12345' ("That's the same combination on my luggage!!!" , and role 'president'
  user.presidentskroob = 12345,president
  # user 'darkhelmet' with password 'ludicrousspeed' and roles 'darklord' and 'schwartz'
  user.darkhelmet = ludicrousspeed,darklord,schwartz
  # user 'lonestarr' with password 'vespa' and roles 'goodguy' and 'schwartz'
  user.lonestarr = vespa,goodguy,schwartz
  
  # -------------------------------
  # Roles with assigned permissions
  # -------------------------------
  # 'root' role has all permissions, indicated by the wildcard '*'
  role.root = *
  # The 'schwartz' role can do anything (*) with any lightsaber:
  role.schwartz = lightsaber:*
  # The 'goodguy' role is allowed to 'drive' (action) the winnebago (type) with license plate 'eagle5' (instance specific id)
  role.goodguy = winnebago:drive:eagle5
  ...
  

• Try to exchange the user to the James Bond user, and you will see you cant login.
• Take note of the very simple use of the security related functions, such as
  currentUser.login(token);
  currentUser.hasRole( “agent” )
  currentUser.isPermitted( “gadgets:astonmartin” )
  currentUser.logout();

In part 2 we will add a text-based security realm.

Using the HTC developer phone the update to Android 1.6 will most probably the last one you can run on this device. Version 2.0 will not run on it (officially)
To update the version from 1.5 to 1.6 you follow the same steps as in my previous blog entry about Android update (link) using the lastest files from HTC (link):

• Radio Image: ota-radio-2_22_19_26I.zip (same file as for 1.5)
• Recovery Image: signed-dream_devphone_userdebug-ota-14721.zip

The release notes of 1.6 (from September 2009) you find at android.com.

If you dare to walk outside the standard path, go to Cyanogen.com for a homebew, but popular mod.

In my previous post I described how to get a EE6 web application using the ZK3.6.3 framework on Glassfish V3. I noted while redeploying or undeploying the web-application it made the GF instance plus the JVM crash (running Ubuntu 9.04,9.10 and JDK 1.6.b16).

This problem does NOT exist anymore with the latest build from last week. Make sure you update to build b72. Start the updatetool in glassfish-home/bin. (you might have to start it several times, I got several times time-out errors, or better click on the reminder if you choose the automatic update check feature).

Glassfish V3b72

As expected, as a matter of not even days, the Netbeans plugin for ZK 3.6.3 was released. Download it from sourceforge.net.

You might also notice they released a plugin for the release candidate of ZK5 (which you find in the same download section). Though the plugin creates a J2EE 1.4 web application, it might be worth installing to test the features of the upcoming version.

I am using Netbeans 6.8B for a few days and mainly testing if my existing JEE5 projects can be opened, deployed and executed on GF3. I am using ZK as Web/Ajax Framework. Usually the ZK team releases a new NB plugin to help you to create ZK based Java Web projects. Currently the plugin supports 3.6.2, some days back ZK 3.6.3 was released, so I guess in a few days time we will have a 3.6.3 plugin. The plugin creates a skeleton for a JEE5 webproject and I doubt they will support Java EE6 before EE6 is finally released (December?).

I was curious to see if I get the latest ZK running on GF V3 as a JEE6 application.

Part 1: ZK 3.6.2 with Netbeans 6.8B as EE5 Web Project

First, lets try first to add the 3.6.2. plugin to NB 6.8B

ZK plugin 3.6.2

Create a new Java Web Project with ZK (under EE5)

Create ZK project (EE5)

Create ZK project (EE5)

Project successfully created with all settings as expected.

ZK Web Project Properties

ZK Web Project Properties

Build, Deploy and Run the project.

Deploying and Running ZK Web project (EE5) in GF V3

That, looks fine. Lets see what the plugin actually does, when you create a new project. It adds the library (project properties) and insert some lines to the web.xml file.

project.properties

..
j2ee.deploy.on.save=true
j2ee.platform=1.5
j2ee.server.type=gfv3ee6
jar.compress=false
javac.classpath=\
 ${libs.ZK3.6.2.classpath}:\
 ${libs.hibernate-support.classpath}
# Space-separated list of extra javac options
javac.compilerargs=
..

web.xml

..
<!-- //// -->
 <!-- ZK -->
 <listener>
 <description>ZK listener for session cleanup</description>
 <listener-class>org.zkoss.zk.ui.http.HttpSessionListener</listener-class>
 </listener>
 <servlet>
 <description>ZK loader for ZUML pages</description>
 <servlet-name>zkLoader</servlet-name>
 <servlet-class>org.zkoss.zk.ui.http.DHtmlLayoutServlet</servlet-class>
 <!-- Must. Specifies URI of the update engine (DHtmlUpdateServlet).
 It must be the same as <url-pattern> for the update engine.
 -->
 <init-param>
 <param-name>update-uri</param-name>
 <param-value>/zkau</param-value>
 </init-param>
 <!-- Optional. Specifies whether to compress the output
 of the ZK loader. It speeds up the transmission over slow Internet.
 However, if you configure a filter to post-processing the
 output, you might have to disable it.

 Default: true
 <init-param>
 <param-name>compress</param-name>
 <param-value>true</param-value>
 </init-param>
 -->
 <!-- Optional. Specifies the default log level: OFF, ERROR, WARNING,
 INFO, DEBUG and FINER. If not specified, the system default is used.
 <init-param>
 <param-name>log-level</param-name>
 <param-value>OFF</param-value>
 </init-param>
 -->
 <load-on-startup>1</load-on-startup><!-- Must -->
 </servlet>
 <servlet-mapping>
 <servlet-name>zkLoader</servlet-name>
 <url-pattern>*.zul</url-pattern>
 </servlet-mapping>
 <servlet-mapping>
 <servlet-name>zkLoader</servlet-name>
 <url-pattern>*.zhtml</url-pattern>
 </servlet-mapping>
 <servlet-mapping>
 <servlet-name>zkLoader</servlet-name>
 <url-pattern>*.svg</url-pattern>
 </servlet-mapping>
 <servlet-mapping>
 <servlet-name>zkLoader</servlet-name>
 <url-pattern>*.xml2html</url-pattern>
 </servlet-mapping>

 <!-- Optional. Uncomment it if you want to use richlets.
 -->
 <servlet-mapping>
 <servlet-name>zkLoader</servlet-name>
 <url-pattern>/zk/*</url-pattern>
 </servlet-mapping>

 <servlet>
 <description>The asynchronous update engine for ZK</description>
 <servlet-name>auEngine</servlet-name>
 <servlet-class>org.zkoss.zk.au.http.DHtmlUpdateServlet</servlet-class>

 <!-- [Optional] Specifies the AU processor for particular prefix.
 <init-param>
 <param-name>processor0</param-name>
 <param-value>/upload=com.my.MyUploader</param-value>
 </init-param>
 -->
 </servlet>
 <servlet-mapping>
 <servlet-name>auEngine</servlet-name>
 <url-pattern>/zkau/*</url-pattern>
 </servlet-mapping>

 <!-- Uncomment if you want to use the ZK filter to post process the HTML output
 generated by other technology, such as JSP and velocity.
 <filter>
 <filter-name>zkFilter</filter-name>
 <filter-class>org.zkoss.zk.ui.http.DHtmlLayoutFilter</filter-class>
 <init-param>
 <param-name>extension</param-name>
 <param-value>html</param-value>
 </init-param>
 <init-param>
 <param-name>compress</param-name>
 <param-value>true</param-value>
 </init-param>
 </filter>
 <filter-mapping>
 <filter-name>zkFilter</filter-name>
 <url-pattern>/test/filter.dsp</url-pattern>
 </filter-mapping>
 <filter-mapping>
 <filter-name>zkFilter</filter-name>
 <url-pattern>/test/filter2.dsp</url-pattern>
 </filter-mapping>
 -->

 <!-- ///////////// -->
 <!-- DSP (optional) -->
 <!-- We need it to show zkdemo correctly (due to categorybar.dsp)
 -->
 <servlet>
 <servlet-name>dspLoader</servlet-name>
 <servlet-class>org.zkoss.web.servlet.dsp.InterpreterServlet</servlet-class>
 <init-param>
 <param-name>class-resource</param-name>
 <param-value>true</param-value>
 </init-param>
 </servlet>
 <servlet-mapping>
 <servlet-name>dspLoader</servlet-name>
 <url-pattern>*.dsp</url-pattern>
 </servlet-mapping>

 <!-- /////////// -->
..

This changes we need to apply if we create a Web project without plugin support.

Part 2: Add ZK 3.6.3 manually to Netbeans as Global Library

In the absence of the plugin (which certainly comes soon) we manually add ZK3.6.3 to Netbeans. I recommend to have the 3.6.2 plugin installed, so we can user the new zul page create assitant. After downloading the release 3.6.3 from the www.zkoss.org we need to create the same structure as for 3.6.2 in the local .netbeans directory. Create a directory zk363.

.netbeans directory structure

Unzip the ZK bin file and copy all jar files (from the different folders under lib) into the new directory zk363. No other files or directories in that folder.

Content of the ZK3.6.3 release (zk-bin-3.6.3)

Now start Netbeans and open the Library Manager (Tools|Libraries) and ‘Add New Library’, name it ZK3.6.3 and add the complete folder from above.

Create Global Library ZK3.6.3

Create Global Library

Now you can add ZK 3.6.3 to any of your web projects.

Part 3: Create EE6 Web Project

Lets create a new JEE6 web project using the just created ZK3.6.3 Library.

New Web Project

New Web Project

New Web Project

Add the global library.

Add ZK3.6.3 Library

First problem: Since we dont have the plugin doing the configuration for us we need to copy the required entries manually (you can copy the complete fragment from the above web.xml).

Second problem: JEE6 works without web.xml, but we still can create and use it.

Create web.xml

Create web.xml

web.xml skeleton

Add the above zk configuration and we have a web.xml like this:

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns="http://java.sun.com/xml/ns/javaee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
 version="3.0">
 <session-config>
 <session-timeout>
 30
 </session-timeout>
 </session-config>

<!-- //// -->
 <!-- ZK -->
 <listener>
 <description>ZK listener for session cleanup</description>
 <listener-class>org.zkoss.zk.ui.http.HttpSessionListener</listener-class>
 </listener>
 <servlet>
 <description>ZK loader for ZUML pages</description>
 <servlet-name>zkLoader</servlet-name>
 <servlet-class>org.zkoss.zk.ui.http.DHtmlLayoutServlet</servlet-class>
 <!-- Must. Specifies URI of the update engine (DHtmlUpdateServlet).
 It must be the same as <url-pattern> for the update engine.
 -->
 <init-param>
 <param-name>update-uri</param-name>
 <param-value>/zkau</param-value>
 </init-param>
 <!-- Optional. Specifies whether to compress the output
 of the ZK loader. It speeds up the transmission over slow Internet.
 However, if you configure a filter to post-processing the
 output, you might have to disable it.

 Default: true
 <init-param>
 <param-name>compress</param-name>
 <param-value>true</param-value>
 </init-param>
 -->
 <!-- Optional. Specifies the default log level: OFF, ERROR, WARNING,
 INFO, DEBUG and FINER. If not specified, the system default is used.
 <init-param>
 <param-name>log-level</param-name>
 <param-value>OFF</param-value>
 </init-param>
 -->
 <load-on-startup>1</load-on-startup><!-- Must -->
 </servlet>
 <servlet-mapping>
 <servlet-name>zkLoader</servlet-name>
 <url-pattern>*.zul</url-pattern>
 </servlet-mapping>
 <servlet-mapping>
 <servlet-name>zkLoader</servlet-name>
 <url-pattern>*.zhtml</url-pattern>
 </servlet-mapping>
 <servlet-mapping>
 <servlet-name>zkLoader</servlet-name>
 <url-pattern>*.svg</url-pattern>
 </servlet-mapping>
 <servlet-mapping>
 <servlet-name>zkLoader</servlet-name>
 <url-pattern>*.xml2html</url-pattern>
 </servlet-mapping>

 <!-- Optional. Uncomment it if you want to use richlets.
 -->
 <servlet-mapping>
 <servlet-name>zkLoader</servlet-name>
 <url-pattern>/zk/*</url-pattern>
 </servlet-mapping>

 <servlet>
 <description>The asynchronous update engine for ZK</description>
 <servlet-name>auEngine</servlet-name>
 <servlet-class>org.zkoss.zk.au.http.DHtmlUpdateServlet</servlet-class>

 <!-- [Optional] Specifies the AU processor for particular prefix.
 <init-param>
 <param-name>processor0</param-name>
 <param-value>/upload=com.my.MyUploader</param-value>
 </init-param>
 -->
 </servlet>
 <servlet-mapping>
 <servlet-name>auEngine</servlet-name>
 <url-pattern>/zkau/*</url-pattern>
 </servlet-mapping>

 <!-- Uncomment if you want to use the ZK filter to post process the HTML output
 generated by other technology, such as JSP and velocity.
 <filter>
 <filter-name>zkFilter</filter-name>
 <filter-class>org.zkoss.zk.ui.http.DHtmlLayoutFilter</filter-class>
 <init-param>
 <param-name>extension</param-name>
 <param-value>html</param-value>
 </init-param>
 <init-param>
 <param-name>compress</param-name>
 <param-value>true</param-value>
 </init-param>
 </filter>
 <filter-mapping>
 <filter-name>zkFilter</filter-name>
 <url-pattern>/test/filter.dsp</url-pattern>
 </filter-mapping>
 <filter-mapping>
 <filter-name>zkFilter</filter-name>
 <url-pattern>/test/filter2.dsp</url-pattern>
 </filter-mapping>
 -->

 <!-- ///////////// -->
 <!-- DSP (optional) -->
 <!-- We need it to show zkdemo correctly (due to categorybar.dsp)
 -->
 <servlet>
 <servlet-name>dspLoader</servlet-name>
 <servlet-class>org.zkoss.web.servlet.dsp.InterpreterServlet</servlet-class>
 <init-param>
 <param-name>class-resource</param-name>
 <param-value>true</param-value>
 </init-param>
 </servlet>
 <servlet-mapping>
 <servlet-name>dspLoader</servlet-name>
 <url-pattern>*.dsp</url-pattern>
 </servlet-mapping>

 <!-- /////////// -->

</web-app>

Finally we create a new zul page (New File..|Web|ZK/zkcanvas)

New File

Name

index.zul

Drag and drop any of the controls (better one that does not require further programming, like the Date picker) and drop it into the zul page.

Deploy and run it. Voila !

index.zul with datepicker in the browser

Last monday we met for the third time. 15 people showed up following in a relaxed 2 hours on these topics:

• Servlet 3.0 (part of EE6) by Chuk
• JVM based languages Clojure, Scala bu Chuk (guess more to come soon once the he add the other languages)
• Pomodoro Time Management by me
• Netbeans, Cobertura, Hudson hands-on by me

You want to join ? Next meetup not yet scheduled. Drop by ww.meetup.com/JUG-Singapore

Quite a number of new releases (that bother me) hit us the last few days (weeks) and more to come.

• Ubuntu 9.10 (the broken Koala) (link)
• Netbeans 6.8 BETA (link)
• Java EE6 in NB 6.8B (official release eventually in December) (link)
• ZK 3.6.3 (link)

Following part 1 and 2 which covered the JUnit test class creation and the coverage evaluation by Cobertura, we will add in part 3 another dimension: Automation. So far we run the tests manually, but we want to achieve a continuous integration and test environment.

Part 3 (Cobertura and Hudson)

Preparation:

• Part 1 (link)
• Part 2 (link)
• Download Hudson (website)
• Running Subversion with the project uploaded
  

Tutorial:

• Download and install Hudson
  Hudson can run standalone (easier for testing, trialing and experimenting) or as a deployed application on an application server.
  Once you downloaded it, just navigate with a terminal session (aka Dos-Box) and start it with “java -jar hudson.war“
  You will get something like this:
  

  Hudson

  I will not go into any details of how to configure Hudson, but jump straight to our project. Maybe in another tutorial I will explain the basic setup of Hudson, but it so simple and the documentation is so good, it is easy for your to do the necessary settings.

• Tweak our Netbeans Project
  As per standard setting when creating a new Netbeans project, the libraries are not kept in the project folder, but copied for deployment only. But Hudson need to access these libraries, one approach to solve this, is to keep the library files in the project folder.
  

  Netbeans Project (Standard Folder)

  

  Local Libraries

  Open the project in Netbeans and open the project properties (right click project name).  In the libraries section you just click Browse and Next.

  

  Libraries

  Once this is done the libraries are kept locally in your project folder.
  Now comes the interesting part, you remember the recommendation from the previous part of the tutorial saying you should modify only the build.xml file ?

  

  build-impl.xml

  Netbeans needs to recreate its build file after our changes. So either we change it for Netbeans and select cancel (not knowing what changes need to be done) or we redo our changes or keep them finally in our own build.xml file.

• Create new Job in Hudson
  Your Hudson is running and you can access it via http://localhost:8080 (assuming you run it as standalone on your local machine)
  You see a mainpage like this
  

  Hudson Portal

  Create new Hudson Job (Build a free-style software project)

  

  Create new Hudson Job

  Configuration of new Job in Hudson

  

  New Hudson Job

  The following parts of the configuration page are interesting for us
  SVN repository

  

  SVN

  Invoke Ant (please note it needs to be downloaded and configured first in the main Hudson configuration)

  

  Invoke Ant

  Trigger JUnit Report Creation (default path is usually **/build/test/results/*.xml)

  

  JUnit Report

  Trigger Corbertura Report (default path is **/build/report/cobertura/coverage.xml)

  

  Trigger Cobertura Report

  All other configuration we dont need right now (I added the email function to drop me an email if the build is broken).

• Trigger the first Build
  

  Job Screen (no build yet)

  

  First Build

  If everything is running fine we should have result like this (inclusive all Ant and JUnit log output)

  ...
  BUILD SUCCESSFUL
  Total time: 10 seconds
  Recording test results
  Publishing Cobertura coverage report...
  Publishing Cobertura coverage results...
  Finished: SUCCESS
  

  Starting with the second build we will see a graph giving us tendencies over the last builds.
  In our sample project we have covered 100% of the classes but only 50% of the lines.

  

  Build Overview

  Test Code 50%
  @Test
  public void testApp() {
  TestMe tst = new TestMe();
  int res = tst.doSomething(3);
  assertEquals(“Correct value”, 0, res);

  //res = tst.doSomething(6);
  //assertEquals(“Correct value”, 2, res);

  //res = tst.doSomething(11);
  //assertEquals(“Correct value”, -1, res);
  }

  Lets re-insert the full test code and we get this after our next build:

  

  Build Overview

Where to go from here:

• Explore all the features of Hudson, eg. Javadoc feature, trigger other builds and use fingerprints.
• Make Hudson production ready by deploying it on an application server such as Glassfish and securing it with logins,..

What else could I plug-in or do:

• There is a huge number of plugins available that help you to integrate with all kind of tools and frameworks.
• You can try the Netbeans Hudson feature (version 6.7 and higher)
• You could try using the Firefox plugin to constantly see the build status.

Following part 1 which covered the class and JUnit class creation and ended in a suspected successful test.

Part 1 (covering Cobertura setup and execution)

Preparation:

• Part 1 (link)
• Download Cobertura (website)
  

Tutorial:

• Extract the Cobertura file (named cobertura-1.9.3-bin.zip, 1.9.3 is the actual version at the time of creation of this tutorial)
  You will find 4 library files (jars) that you need to copy somewhere. I copied them into my ANT folder under Netbeans for this tutorial, but I would recommend to copy the files into the lib folder of your project.
  

  Cobertura Tutorial

  

  Cobertura Tutorial

• Add the libraries to our project
  Project Properties|Libraries|Run Test folder
  As I remarked before, here I point to a relative path outside my project folder which is not good practice.
  

  Cobertura Tutorial

• Modify the Netbeans project properties file
  There is currently no Cobertura plugin available for Netbeans (at least I am not aware of one, except one on project kenai server, but it’s not implemented yet)
  Open the file explorer view of our project and opent he file project.properties (which is created by Netbeans and updated when we change project settings). For serious projects I recommend to always make a copy before manually changing its content.
  We add 3 lines for our instrumented class files.
  

  Cobertura Tutorial

  

  Cobertura Tutorial

  # FOR COBERTURA
  build.instrumented.dir=${build.dir}/instrumented
  build.report.dir=${build.dir}/report
  build.report.cobertura.dir=${build.report.dir}/cobertura
  

• Modify the Ant build script
  Ant can do a lot, Maven maybe more. I am not an Ant expert, but at least I could bend  my brain around it and figure out how it works. So far I was the lazy Netbeans user “what is ant?”
  I will not explain Ant (curious readers can proceed to ant.apache.org), but you should understand the concept of tasks and dependencies.
  Netbeans creates to build files: a build.xml in your project root and a build-impl.xml in the nbproject subfolder. You are advised to add ant tasks in the build.xml file, the other file is maintained by Netbeans.
  First we need to tell ant to create the instrumented class files (Cobertura add some stuff to each line of our byte code). The instrumented bytecode is kept separately and does not affect our production classes.
  open the build.xml file, it should be empty except some header (that also imports the other buildfile) and some remarks explaining how it works. Right at the end (before the </project>)  we add this

  <property environment="env"/>
  <taskdef classpath="cobertura.jar" resource="tasks.properties"/>
  <target name="-pre-compile-test">
   <delete dir="${build.instrumented.dir}" />
   <delete dir="${build.report.cobertura.dir}" />
   <mkdir dir="${build.instrumented.dir}" />
   <mkdir dir="${build.report.cobertura.dir}" />
   <cobertura-instrument todir="${build.instrumented.dir}">
   <fileset dir="${build.classes.dir}">
   <include name="**/*.class"/>
   </fileset>
   </cobertura-instrument>
  </target>
  

  It is not a new task (there are no dependencies here) but it overrides the task with same name in the build-impl.xml file.

  <    <target name="-post-compile-test">
   <!-- Empty placeholder for easier customization. -->
   <!-- You can override this target in the ../build.xml file. -->
   </target>
  

  Every time we test the whole project this task is called and will create the instrumented class files for us.

• Modify the class path for test execution
  This is the part which I didnt figure as fast. The cobertura result was created and always showed 0% coverage. You need to tell Netbeans/Ant to use the instrumented classes for the test not the regular ones in your build folder.
  

  Cobertura Tutorial

  Open the project.properties file again and make sure to add the line ${build.instrumented.dir}:\ before your regular build path.
  Note the entries with ${file.reference.asm-3.0.jar}:\ were added by Netbeans when we added the Cobertura libraries. You could adjust the classpath order using the project properties as well.

  javac.test.classpath=\
   ${javac.classpath}:\
   ${build.instrumented.dir}:\
   ${build.classes.dir}:\
   ${libs.junit_4.classpath}
  ..
  run.test.classpath=\
   ${javac.test.classpath}:\
   ${build.instrumented.dir}:\
   ${build.test.classes.dir}:\
   ${file.reference.asm-3.0.jar}:\
   ${file.reference.asm-tree-3.0.jar}:\
   ${file.reference.cobertura.jar}:\
   ${file.reference.jakarta-oro-2.0.8.jar}:\
   ${file.reference.log4j-1.2.9.jar}
  

  Executing the test for our project now will use the instrumented classes and creates a coverage result files for us (cobertura.ser, NO, you cant open the file in the editor)

• Modify the build script to convert the result file in human readable websites.
  I do this (breaking the previous rule) in the build-impl.xml file, but it would be fairly easy to migrate this to “our” build.xml file.
  Look for this section

   <target depends="init,compile-test,-pre-test-run,-do-test-run" if="have.tests" name="-post-test-run">
   <fail if="tests.failed">Some tests failed; see details above.</fail>
   </target>
  

  and ammend it:

   <target depends="init,compile-test,-pre-test-run,-do-test-run" if="have.tests" name="-post-test-run">
   <fail if="tests.failed">Some tests failed; see details above.</fail>
   <!-- You can disable the html portion if you are using the hudson plugin and rely on the xml -->
   <cobertura-report format="html" srcdir="${src.dir}" destdir="${build.report.cobertura.dir}"/>
   <!-- Used by the hudson plug-in -->
   <cobertura-report format="xml" srcdir="${src.dir}" destdir="${build.report.cobertura.dir}"/>
   <delete file="cobertura.ser" />
   </target>
  

• Execute the tests and enjoy the results
  You trigger the test for the whole project and your output will be like this

  init:
  deps-jar:
  compile:
  Deleting directory /home/sven/NetBeansProjects/CoberturaDemo/build/instrumented
  Deleting directory /home/sven/NetBeansProjects/CoberturaDemo/build/report/cobertura
  Created dir: /home/sven/NetBeansProjects/CoberturaDemo/build/instrumented
  Created dir: /home/sven/NetBeansProjects/CoberturaDemo/build/report/cobertura
  Cobertura 1.9.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
  Cobertura 1.9.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
  Instrumenting 1 file to /home/sven/NetBeansProjects/CoberturaDemo/build/instrumented
  Instrumenting 1 file to /home/sven/NetBeansProjects/CoberturaDemo/build/instrumented
  Cobertura: Saved information on 1 classes.
  Cobertura: Saved information on 1 classes.
  Instrument time: 77ms
  Instrument time: 77ms
  compile-test:
  Testsuite: demo.TestMeTest
  Smaller than 5
  Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.099 sec
  
  ------------- Standard Output ---------------
  Smaller than 5
  ------------- ---------------- ---------------
  Cobertura: Loaded information on 1 classes.
  Cobertura: Saved information on 1 classes.
  test-report:
  Cobertura 1.9.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
  Cobertura 1.9.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
  Cobertura: Loaded information on 1 classes.
  Cobertura: Loaded information on 1 classes.
  Report time: 251ms
  Report time: 251ms
  Cobertura 1.9.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
  Cobertura 1.9.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
  Cobertura: Loaded information on 1 classes.
  Cobertura: Loaded information on 1 classes.
  Report time: 107ms
  Report time: 107ms
  Deleting: /home/sven/NetBeansProjects/CoberturaDemo/cobertura.ser
  test:
  BUILD SUCCESSFUL (total time: 3 seconds)
  

  You still will end up seeing the JUnit test result pane with “test passed”, but lets go to the report folder in our project and open the index.html file (Ignore the coverage.xml file because it is used by theHudson plugin that we will discuss in part 3)

  

  Coberture Tutorial

  Ops, there is still something in red !

  

  Corbertura Tutorial

  Cobertura tells us exactly which part of our method was never touched by our tests !

  

  Corbertura Tutorial

• Increase the code coverage|
  Lets go back to our project and add test cases

  ..
   @Test
   public void testApp() {
   TestMe tst = new TestMe();
   int res = tst.doSomething(3);
   assertEquals("Correct value", 0, res);
  
   res = tst.doSomething(6);
   assertEquals("Correct value", 2, res);
  
   res = tst.doSomething(11);
   assertEquals("Correct value", -1, res);
   }
  ..
  

  and test again

  

  Cobertura Tutorial

  Voila ! All lines and branches are covered. 100% (Find my remark later)…GREEN all over.

  

  Cobertura Tutorial

Resume:
I love this tool. Thanks for creating it. I cant add quality to the source (it is open source) but at least I could create this tutorial for more folks to get started. Use Corbertura !
I will try Corbertura with Hudson in the next part and also try it on web applications.

2 more remark:
Dont let fool yourself in the assumptions that covering all lines in your codebase really reflects a complete test, you still need to test the business logic of your application against various use cases !
In reality 100% coder coverage is not realistic. The complexity explodes with combination of for/while loops combined with if statements, and also platform dependendant or very exceptional parts might not be possible to be covered. But try your best
References:
I could not get the tutorial running without using this pre-existing fragments/snippets/ideas and websites

• http://cobertura.sourceforge.net
• http://ant.apache.org/
• http://wiki.netbeans.org/CoberturaAnt
• http://www.devdaily.com/blog/post/java/sample-cobertura-ant-build-script/
• http://www.ibm.com/developerworks/java/library/j-cobertura/
• http://weblogs.java.net/blog/fabriziogiudici/archive/2007/02/automating_test.html
• http://cobertura.sourceforge.net/mavenCobertura.html
• http://kenai.com/projects/nbcobertura

Update (2009-09-25):
There is a problem with the path of Cobertura. The above tutorial only works because the 4 jar files are in the ant folder, which is in the path !  I realized this after testing the project in a different environment.

I believe strongly in testing. I saw companies and products without any automatic test frameworks and the slightest change to the codebase (often in the urgent ‘we-need-to-fix-it-now-and-give-to-the-customer-in-1hr’ mode) made parts of the product or modules prone to crashes because no one could test the changes against the complete application. In my current endevour to create a new product we embrace testing, though we dont practice TDD (test-driven-development), but at least we maximize the amount of automatic testing with tools/frameworks like Netbeans, Hudson, Cobertura and others. If you dont practice TDD, how can you judge how much of your codebase is really tested, even you assume all you business testcases are covered ?

The other day Code Coverage crossed my way (Thanks Chris!). Eager to find out how to “do it” or to “use it” I found a few tools suitable for the Netbeans environment. It actually drilled down to only one tool: Cobertura. It fits exactly into our landscape using Netbeans and Hudson and it is opensource.
To get started with Cobertura you should be familiar (a bit) with Netbeans, JUnit and Ant. The Cobertura website offers sufficient reference for all functions and introduction to get you started. But what I missed is a tutorial the start from the scratch using Netbeans and Cobertura. I found 3 references (I will add them at the end,) which are not complete or just not working for me), so let me share the most basic getting-started steps with you.
Please note: This is how I get started, it might not be complete, foolproof or even correct in all details. Please feel free to comment, correct or give other feedback !

Part 1 (covering project creation and JUnit test)

Preparation:

• You have basic knowledge of Java and Netbeans.
• Netbeans 6.5.1 (I guess older or newer versions work also)

Tutorial:

• Create a new Java Project using the new project wizard of Netbeans
  Call it CoberturaDemo. Deselect create Main class.
  

  Cobertura Tutorial

  

  Cobertura Tutorial

• Create a new class
  Name it TestMe in the package demo
  

  Cobertura Tutorial

• Add some basic functionality that we can test later.
  It is only a function that checks an int value if smaller than 5 or even in 2 if {} statements and returns 0 or 2. Useless function but we have something to “code-cover” !
  

  Cobertura Tutorial

  package demo;
  
  public class TestMe {
  
   public int doSomething(int i) {
   if (i < 5) {
   System.out.println("Smaller than 5");
   return 0;
   }
  
   if (i % 2 == 0) {
   System.out.println("Even number");
   return 2;
   }
  
   return -1;
   }
  }
  

• Add JUnit Test Skeleton for our class
  By right-click the TestMe.java file in the demo package. Tools | Create JUnit test.
  For this tutorial we leave the defaults since we are not discussing them.
  Netbeans will create a test skeleton file for you (TestMeTest.java)..
  Comment: TestMe.java was not a good name choice. All Junit Test files are called {yourClassName}Test.java.
  

  Cobertura Tutorial

  

  Cobertura Tutorial

• Create a real JUnit test
  The skeleton does NOTHING for us, so we need to add a test. You believe Netbeans creates testcases for you ?
  We create a simple test, only 1 for now, that throws a value at the method and checks for the expected value.
  

  Cobertura Tutorial

  package demo;
  
  import org.junit.Test;
  import static org.junit.Assert.*;
  
  public class TestMeTest {
  
   public TestMeTest() {
   }
  
   @Test
   public void testApp() {
   TestMe tst = new TestMe();
   int res = tst.doSomething(3);
   assertEquals("Correct value", 0, res);
   }
  }
  

• Execute JUnit test
  We are already at out first testing stage ! Note that java class cannot be run, but the JUnit test.
  Right click on the project (project explorer) and select Test.
  You should get something like this:
  

  Cobertura Tutorial

  You can experiment, aka break it, by changing the expected value to 99 and execute test again.

Resume Part 1:
We crceate a Java class and a JUnit test class for it. We executed the test and saw “test passed”. We could belive “my class is tested ! lets move on..“.
NO ! Half the code is NOT tested and JUnit wont tell us either ! Of course it is obvious for this most simple sample, but just think about your projects that are usually a bit more complex. Would you “see” it, if not everything is covered ? Certainly NOT. So we need a tool to tell us.

Part 2 will introduce Cobertura as our new magic wizard to our demo project.
Part 3 will cover Hudson and the Cobertura plugin for Hudson.

Stay tuned.