I’ll demonstrate the technique with an Ant target that I wrote to check whether Ivy had downloaded any jars that had the pattern SNAPSHOT in their name:

<target name="ivy-count-snapshot-jars" depends="init" if="ivy.present">
    <resourcecount property="ivy.snapshot.count">
        <fileset dir="${ivylib.dir}" includes="**/*SNAPSHOT*.jar"/>
    </resourcecount>
    <condition property="ivy.snapshot.present">
        <not>
            <equals arg1="${ivy.snapshot.count}" arg2="0"/>
        </not>
    </condition>
</target>

<target name="ivy-check-snapshot-jars"
        depends="ivy-count-snapshot-jars"
        if="ivy.snapshot.present">
     <echo>WARNING: Project uses ${ivy.snapshot.count} SNAPSHOT jar(s).</echo>
</target>

The first target does most of the work and is used to count the number of jar files with ‘SNAPSHOT’ in their name; it also sets a property if the count is not zero.

The second target is the main one that should be used to perform the check. It depends on the first target (ensuring that the count is done first) and will only then run if the first target sets the ‘ivy.snapshot.present’ property. Thus the warning message will only get echoed if there are snapshot jars in the project.

One common problem faced when unit testing is how to test one object when it is dependant on another object. You could create instances of both the object under test and the dependent object and test them both together, however testing aggregated objects is not what unit testing is about – unit tests should test individual objects for their correct behaviour, not aggregations of objects! Moreover, this approach just won’t work if the dependent object hasn’t even been implemented yet.

A common technique for handling dependencies in unit tests is to provide a surrogate, or “mock” object, for the dependent object instead of a real one. The mock object will implement a simplified version of the real objects methods that return predictable results and can be used for testing purposes.

The drawback of this approach is that in a complex application, you could find yourself creating a lot of mock objects. This is where frameworks like Mockito can save you a lot of time and effort.

A Test Scenario

To demonstrate what you can do with Mockito, we’ll examine how we might test an Account object that is dependant on a data access object (AccountDAO).  The account object can calculate the charges applicable in the current month by using the DAO to count the number of days overdrawn and then performing a simple calculation on the value obtained from that call. The method names on the classes we’ll use are self-explanatory:

To test this thoroughly, we should test two things:

1. that the account obtains the number of overdrawn days by calling the correct method on the DAO,
2. that the account calculates the correct fees based upon the value it gets back from the call.

Testing that the account calls the correct method on the DAO

Using JUnit to run the test case, we could write something like this:

import static org.mockito.Mockito.*;

public class TestAccount {
    @Test
    public void checkAccountCallsDaoMethods() {
        //create the object under test
        Account account = new Account();

        //create a mock DAO
        AccountDAO mockedDao = mock(AccountDAO.class);	

        //associate the mocked DAO with the object under test
        account.setDAO(dao);

        //call the method under test
        long charge = account.calculateCharges();

        //verify that the 'countOverdrawnDaysThisMonth' was called
        verify(mockedDao).countOverdrawnDaysThisMonth();
    }
}

Taking centre stage in all this is the Mockito class which has a bunch of static methods that are used within the unit test (note the static import on line 1).

The call to the ‘mock’ method (line 10) creates a mock object that can be used in place of a real AccountDAO. The call to ‘verify’ (line 19), will throw an exception if the ‘countOverdrawnDaysThisMonth’ method was not called on the mock object.

It is worth noting here that this is a simple example which just demonstrates the basic principle of verification, it is also possible to use the verify method to check for parameter values and ranges in the method call too.

Testing that the account performs its calculations correctly

In the above example, we mocked the DAO but didn’t specify what any of the mocked methods should do. In this case, all methods will return sensible default values of: null, zero or false. More commonly we need to specify something other than these defaults when writing our tests:

import static org.mockito.Mockito.*;
import static junit.framework.Assert.*;
import org.junit.*;

public class TestAccount {
    private Account account;

    @Before
    public void setup() {
        AccountDAO mockedDao = mock(AccountDAO.class);

    	//specify that this method on the mock object should return 8
        when(mockedDao.countOverdrawnDaysThisMonth()).thenReturn(8);

        account = new Account();
        account.setDAO(dao);
    }

    @Test
    public void checkChargesWhenOverdrawn() {
        //call the method under test
        long charge = account.calculateCharges();

        //assert that the charge was £2 per day overdrawn
        assertEquals(charge, 16);
    }
}

The statement on line 18 specifies that whenever the ‘countOverdrawnDaysThisMonth’ is called it should return a value of 8; overriding the default of zero.

Given that the correct charge is two pounds (or dollars) per day overdrawn, then the assertion on line 25 will pass if the account performed the correct calculation (8 x 2 = 16 right).

Comments

There’s loads more to Mockito than we’ve looked at here. It’s a neat testing tool that works great with JUnit or TestNG. I’ve found that it’s small enough to learn quickly and capable enough to be really useful. Give it a go and write a comment below to let me know what you think of it.

It’s not often that changes to MySQL configuration need to be made. This post is, therefore, more a reminder to myself than anything else.

First locate the configuration file. On my Mac I found this empty configuration file had been created as part of the installation process:

/etc/my.cnf

You’ll need super-user privileges to update it. I used:

sudo vi /etc/my.cnf

Enter the configuration settings you require. I wanted to update the maximum packet size so I entered:

[mysqld]
max_allowed_packet=16000000


Then you should be able to stop MySql with:

mysqladmin -u root -p shutdown


Restart it using whatever start script you prefer. To make sure that your changes have taken effect you can print the server variables to the console with:

mysqladmin -u root -p variables


There are two ways to ignore files in svn: global settings and local. Global settings configure the users environment with some rules for ignoring files, but generally the local ignores are more useful and will be discussed here.

Most projects have files that should be ignored and not included in the version repository. For example, in Java projects, the compiler output shouldn’t be included as these can be regenerated from the source anyway. You might also have temporary cache files being generated, or output from running unit tests that you don’t want to share too.

Ignoring files and directories

Each directory in a svn managed project has a sub-directory called .svn which contains configuration information that svn uses when working in that directory. To make svn ignore certain content within a directory you need to configure an svn:ignore property for it.

To demonstrate this let’s work with the following project directory structure:

myproject/log-2009-12-01.txt
myproject/log-2009-12-02.txt
myproject/build/classes

First let’s tell svn to ignore the log files that have been created. I’m using SVN 1.5.4 on a Mac so I’ll demonstrate this using a command line but you could do much the same using a GUI tool like Tortoise:

$ svn propset svn:ignore 'log-*.txt' myproject

The above command has used the propset command to set the svn:ignore property value to log-*.txt for the myproject directory.

Note that it is possible to use a wild-card ‘*’ as part of the file name. You can also use the ‘?’ symbol to match a single character in a file name but svn does not currently support any more powerful matching features.

Importantly note also that the file name must be quoted in order that the literal value is passed to the svn command; without this the shell will process the wild-card and pass all matching file names instead.

You can inspect the value of this property using the propget command like this:

$ svn propget svn:ignore myproject
log-*.txt

An ignore property can also be applied to directories, causing all files and sub-directories within it to be ignored. To make svn ignore the classes directory and its contents we could use the command:

$ svn propset svn:ignore 'classes' myproject/build

Setting multiple ignore rules within a directory

So far we’ve looked at how we can set an individual ignore rule within a directory using the propset command. Although both of the rules we’ve demonstrated have resulted in multiple files being ignored, either by using a wild card syntax or by specifying a directory whose content will also be ignored, we’ve not yet discussed is how these rules can be combined within a directory; for example: to ignore all log files and also a sub-directory:

/myproject/log-2009-12-01.txt
/myproject/log-2009-12-02.txt
/myproject/classes

The svn:ignore property is actually a list of file name patterns that svn must ignore. The propset command simply overwrites that list with a single line that includes the pattern you specify when you issue the command.

To create a list of file names that will be matched, use the propedit command instead:

$ svn propedit svn:ignore myproject

Your svn editor will then be started and you can edit the list of filenames that must be ignored. For our example it would need to look like this:

log-*.txt
classes

Note that each file name pattern must be on a separate line.

Ignoring versioned files and directories

You must be aware that the svn:ignore properties only apply to any files that are not under version control.

In practical terms this means if you accidentally add a file or directory to your version control, you will need to explicitly issue a svn delete command (rm) in order that svn will ignore the files.

Commands like add and import work recursively in svn, so it’s easy to accidentally add files like those mentioned above to a versioned project. For example if our log files were accidentally added we could issue this command to delete them from svn:

svn rm log*.txt

Note this time that the filename is not quoted as we want the shell to pass all log files to be deleted.

After committing the changes to the project, the files will no longer be managed by svn and the ignore properties will once again work.

After a little experimenting, I figured out the following commands could be combined as illustrated below:

From within the project root folder this command can be used to list all of the .svn directories:

$ find . -type d -name .svn

If your directory names don’t have spaces or quotes in them, then you could just pipe the find command directly into xargs and rm to delete them all:

$ find . -type d -name .svn | xargs rm -rf

If you do have spaces or quotes in your directory names, then you need to change the newlines returned from find into null characters (notice the -print0 flag), and make xargs use this to split the input into individual file names (see the -0 flag) rather than the newlines, spaces and quotes that it normally looks for:

$ find . -type d -name .svn -print0 | xargs -0 rm -fr

The above command will delete all directories named ‘.svn’, regardless of whether they have spaces, or quote characters in their names.

It’s much better to work in a branch and to merge the changes once you’re convinced they are stable. This post demonstrates how to do this using the Subversion command line tools; however, the same principles would apply if you were using a GUI tool like Tortoise for example.

Creating a branch

Creating a branch is simple. You just copy the revision you want to make changes to into the branches folder of your project in the SVN repository, for example:

svn copy http://svnserver/myproject/trunk http://svnserver/myproject/branches/stevescopy

This will create a copy of the head revision in the project called ‘myproject’ in a branch folder called ’stevescopy’ on the SVN server found at ’svnserver’.

You may notice when doing this that the copy operation completes very quickly, this is because no files are actually copied, SVN just copies markers to file versions making branching a very cheap and fast operation to perform.

Next you should check out the branch before working on it in the usual manner. So, following the previous example, we could check out our branch using:

svn co http://svnserver/myproject/branches/stevescopy .

When working on the code in the branch, you should feel free to commit changes as frequently as you like. The changes that you make are now completely separate from the head revision.

Merging changes back to the trunk

When you’re ready to merge whatever updates you’ve been working on back into the trunk, you should first commit all changes in your branch. To do this, issue the SVN commit command from the working directory of your branch:

svn commit -m 'committing the branch before merging'

Next, in a separate directory, check out the version of the project that you want to merge your changes into. In our case we want to merge our changes back into the head revision:

svn co http://svnserver/myproject/trunk .

Now we can perform the merge. The merge does not change the data held in the repository, instead it updates the local copy that we have just checked out. So, from the directory into which we just checked out the trunk, we should issue a command to merge the changes from our branch:

svn merge http://svnserver/myproject/branches/stevescopy

SVN will now update all the files in this working copy with the changes made in our branch. If there are conflicts (i.e. another user has updated the original trunk files since you checked them out) then SVN will detect this and it will ask you to resolve them. Once completed, you should check that your project builds and passes all of its tests before committing your merged copy back to the trunk:

svn commit -m 'committing with updates from the stevescopy branch'

Cleaning up

If you don’t plan to do any more work on the branch, you can delete it using something like this:

svn rm http://svnserver/myproject/branches/stevescopy

In this post I’ll demonstrate how the same principle can be applied in a Grails application.

Basically, just about everything from the previous post is the same, except for how the filtering of requests and the sending of the cookies from the host application is performed.

In Grails it is simple to write web filters. Just create a Groovy class with a name that ends with ‘Filters’ in your conf folder and add closures that define the filtering behaviour:

class MyFilters {
    def filters = {
        myFirstFilter(controller: '*', action: '*') {
            before = {
                  //code here is executed before the controller has been accessed
            }
            after = {
                  //code here is executed after the controller has been accessed
            }
            afterView = {
                  //code here is executed after the view has been rendered
            }
        }
    }
}

in this example, there is a single filter called ‘myFirstFilter’ that will be applied to all actions on all controllers, which illustrates the three filtering points available in Grails.

So given a Grails application service called ‘userService’ that returns us a domain object for the currently logged in user, then we could write a cookie sending filter which uses the SSO plug-in like this:

class SecurityFilters {
  def userService;

  def filters = {
    jForumSecureSSOCookie(controller: '*', action: '*') {
      after = {
        if (userService.getUser()) {
          def user = userService.getUser();
          def encryptedValues = SecurityTools.getInstance().encryptCookieValues(user.email, user.username);

          Cookie c = new Cookie(SecurityTools.FORUM_COOKIE_NAME, encryptedValues)
          c.maxAge = -1;
          c.path = "/"
          c.comment = "SSO cookie for language spider forum"
          response.addCookie(c)
        } else {
          //user is not logged in so kill the cookie
          //(removing cookies does not work reliably in all browsers)
          Cookie c = new Cookie(SecurityTools.FORUM_COOKIE_NAME, "")
          c.maxAge = -1;
          c.path = "/"
          c.comment = "SSO cookie for language spider forum"
          response.addCookie(c)
        }
      }
    }
  }
}

Because, Grails runs in a Java environment, all other configuration, including the JAR file deployment remain as discussed in the previous post.

As the SSO code I wrote didn’t have any dependency on our applications classes, I decided to package and release it as a JAR file that anyone can use.  If you’d like to use it, then you can download it from the tools page on this website; instructions on how it words and how to configure JForum to use it are detailed below.

Integrating JForum into an existing application

JForum is indented to be used as either a stand-alone forum, or as an integrated solution for existing sites. The simplest way to integrate JForum with an existing application is simply to deploy it as a second named application under the same domain. For example, if your application is running on a server at:

http://www.myapplication.com/

then just run the JForum application under the same domain as a separate application, for example:

http://www.myapplication.com/forum

you can then just link to it from your web pages. Customise the JForum page templates to look like those from your own application and you’re almost done.

The last thing that you’ll want to do is automatically log users in to the forum once they’re logged into your application. If you don’t do this then your users will have to re-register with JForum just to use the forum pages! Fortunately, JForum ships with a simple SSO module. Unfortunately it’s not very secure.

If you’re running JForum on the same domain as the application your are integrating it with, then cookies set by one application will be visible to the other; as far as the browser can tell, its interacting with a single application. The standard SSO solution that ships with JForum exploits this fact and if your application sets a cookie with the user’s screen name and email address, JForum will automatically log them in to the forum pages for you.

This is a neat and simple solution but it does have a real security hole. If a hacker decides that they want to log into the forum and post messages as another user, then all they need to do is make their browser send a cookie with the name and email details of the users account they want access and JForum will then just log them into it. This is easy to do with something like Firefox’s firebug plug-in and doesn’t require any great skill.

JForum does provide an API with hooks for implementing your own SSO integration. In the JForum documentation, the example demonstrates how, in addition to receiving the user’s credentials (again via a plain text cookie), you could make calls to your database to access further user information. This does not address the security issue outlined above. Further work is required to achieve this.

A more secure solution

In the solution I developed, rather than sending a plain text user name to JForum in a cookie, an encrypted value is passed between the applications instead. By using a strong encryption algorithm it is possible to authenticate the user just once in the main application, and then send an encrypted token in the cookie that can be used to authenticate the user in JForum. This approach has the distinct advantage of preventing any hackers from being able to spoof user names by simply sending them in a cookie.

So, for example, if you encrypt your user’s name and email address before sending them in a cookie, anyone examining the cookie data will see something resembling:

b259fa5bb42d8c53280c54bbb16d9b814574443d903eb85ba5594ef58b374c8d

this can be decrypted by JForum and the users name and email address retrieved from it.

Configuring and using the JForumSecureSSO plug-in

The steps involved to use this plug-in are:

1. Change the default encryption password used
2. Install the JAR file in each of the applications
3. Implement a cookie filter for your application
4. Configure JForum to use your encrypted cookie

Lets look at these in more detail:

1. Change the default encryption password used

If you take a look in the META-INF folder in the jforum-secure-sso.jar file you’ll find a properties file that contains a property called security.password. The default value for this property is ‘change this’.

This property value is the password used by the encryption libraries as a seed for the encryption that is carried out on the cookie data. Update the JAR file by changing the password to a value that only you know – you should make this at least 16 chars long.

Note that you won’t use this password anywhere else in your application so you could just enter some random characters here.

2. Install the JAR file in each of the applications

Copy the JAR file with the modified password into the WEB-INF/lib folders of both your application and JForum too. This ensures that the encryption routines in the JAR files will now both be using your secret password when encrypting/decrypting the data.

3. Implement a cookie filter for your application

In order to ensure that an encrypted cookie is sent for any authenticated users, you’ll need to add a little functionality to your application.

There are a number of variations on how you might do this depending on the security system that you are using. For this reason, there are no classes in the JAR file that do this for you – time for you to cut a little code!

Generally, the best way to send the cookie will be from within a Web Filter. These are a standard feature since Servlet 2.3 specification and are are supported by all but the most antique application servers. The filter should be applied to all URLs that your application supports and will need to send an encrypted cookie, something like this:

import uk.co.smartkey.jforumsecuresso.SecurityTools;

//get your user's details from wherever they are available in  your application
User user = session.getAttribute('user');

//encrypt them using your secret password
String encryptedData = SecurityTools.getInstance().encryptCookieValues(user.getEmail(), user.getUserName());

//send the cookie using the predefined cookie name
Cookie c = new Cookie(SecurityTools.FORUM_COOKIE_NAME, encryptedData)
c.maxAge = -1;
c.path = "/"
response.addCookie(c)

4. Configure JForum to use your encrypted cookie

In the JForum configuration file, you’ll need to set the following properties to ensure that your data is loaded and used to log your users in using SSO:

authentication.type=sso
sso.implementation=uk.co.smartkey.jforumsecuresso.JForumSecureSSO
sso.redirect=http://www.myapplication.com/login.jsp

More details of these settings are available at the JForum web site.

Comments

If you think this could be of use to you, then you can download the distribution files from our tools page. This project has been tested to work with JForum 2.1.8 running on Tomcat 6 and is built using Maven. The source code is included in the distribution and is released using the same BSD license as JForum. If you’d like to add any functionality, I’ll be happy to include it in a future release.

Now I’ve got to admit to being a big fan of IDEA. I’ve been using it for years now, and as the IntelliJ people have been saying all along: “it’s the best Java IDE that money can buy“. Well now it looks like it may well be the best free Java IDE too!

If you’ve not tried it, then now might be the perfect time to download it and give it a go. I can guarantee that after you’ve invested a little effort in figuring out what it can do for you, your productivity will increase dramatically. And that’s what’s always been key for me: if the time I save using the tool costs me less than the license fee, then it’s a no-brainer: pay up and work more efficiently. It’s  a simple value-for-money decision.

So what can it do? Well, for example, can your IDE attach to your database, load the schema and then give you code completion in the SQL strings that you write when programming JDBC? Work with Hibernate instead? Then maybe you’d appreciate the code completion for your HQL queries and also in  your mapping files. Want a UML diagram generated from your source code? No problem. If you’re a fan of Spring, then you might like the graphical view of the dependencies in a Spring application context? Need to see if your Spring pointcut syntax is right? Then a keyboard shortcut to view the advised methods on your beans will help with that. I could go on and on, but you probably get the idea.

Now this is where things get a little complicated. The JavaEE and framework features I’ve listed above won’t be available in the open-source, or “community”, edition. The JavaEE support is reserved for those that are still prepared to pay for it. Fair enough you might say; if you want better JavaEE support in Eclipse you’ll likely choose to use MyEclipse which currently costs over $150 and offers some of the best support available for Web development in that IDE. And I’d have to agree with  you: you pays your money, you takes your choice.

Regardless of this, the features available in the community edition of IDEA still far exceed those available in most other free Java IDEs and, in my opinion, are more reliable and robust oot. IDEA not only provides Java coding support but also XML, Groovy and regular expression syntax too. Add to this Live Templates (a build in macro language for automating common code generation, like iteration over collections/arrays for example)  and you’ve got a feature set that will keep most Java developers very happy. For a complete comparison matrix of the features that are available in the community and the ultimate editions, take a look at this link.

This seems to me to be a very clever marketing decision by IntelliJ. They are clearly aware that their greatest barrier to mass adoption is not the quality of the IDE, but the price of a license, and that by releasing this edition of their application they have completely eliminated this.

Good move I say, and good luck.

Packaging Midlets

Packaging Midlets can be a complex process. Firstly, there are requirements for two files to be created: a Jar and a Jad file. The Jar file will contain all of the classes and other resources that the application requires, and the Jad file will contain entries which describe the contents of the Jar. In both the Jar and the Jad files, there are a number of mandatory entries that must be made. Among other things, the manifest in the Jar must, for example, specify the application version and the Jad file must specify the exact size of the Jar file.

If any of the entries in either of these files is incorrect, then your application may not work on a some devices; and the only way to check that an incorrectly packaged application works on all devices is to test it on all devices. Very impractical – a far better solution, obviously, is to correctly package the application in the first place.

Antic is an Ant task that can be used in conjunction with any standard Ant release. Antic fills a gap in the standard Ant tasks’ functionality and provides capabilities for packaging Java ME applications. All other related Java ME build functionality can automated with the standard Ant tasks.

Using Antic in an Ant build files

A typical Antic entry in a build file might look like this:

<taskdef name="antic"
classname="uk.co.smartkey.util.anttasks.AnticTask"
classpath="antic.jar"
/>

<target name="package" depends="compile">
<antic suiteName="Demo Suite"
version="1.0"
vendor="smartkey.co.uk"
profile="MIDP-2.0"
configuration="CLDC-1.1"
jarName="demo.jar"
jadName="demo.jad"
jarURL="http://www.smartkey.co.uk/demo.jar">

<midlet name="First Midlet" classname="MessageMidlet"/>
<midlet name="Second Midlet" classname="DisplayMidlet"/>

<attribute name="message" value="Hello World!!!"/>

<fileset dir="${build}" includes="**/*"/>
<fileset dir="${images}" includes="*"/>
</antic>
</target>

Above, we can see that before we can use Antic, we must use the Ant taskdef element to declare a new task that we will use in this build file; with this we must specify the name, class, and classpath for the task.

We then define an target named ‘package’. This target uses Antic to create a Jar file called ‘demo.jar’, and an associated Jad file called ‘demo.jad’. All mandatory entries for the Jar file’s manifest and the Jad file are specified at attributes on the Antic task.

Within the Antic task there are two of midlet elements to describe each midlet in the suite; in this particular example there are two, called ‘First Midlet’ and ‘Second Midlet’. Attributes can also be specified for the midlet suite, this is shown on the next line. The last elements within the Antic task are filesets; these specify the files that must be added to the Jar file; there must be at least one fileset element here.

If you’d like to use Antic to build your own J2ME applications, then go to our tools page where you can download the current release.