btaz

I wanted to add the Spring 3.0 M4 milestone early access release to a Maven project to test out some of the new features. However Spring  milestone releases are not readily available in the standard public Maven repositories, so what do you do?

For the full explanation check out the link to “Spring/Maven Repositories” link in the bottom. For a quick 1-2-3 step solution add this to the <repositories> section in your Maven pom.xml file so that Maven can find Spring’s early access milestone releases:

<repository>
  <id>spring-milestone</id>
  <name>Spring Portfolio Milestone Repository</name>
  <url>http://s3.amazonaws.com/maven.springframework.org/milestone</url>
</repository>

<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-core</artifactId>
  <packaging>jar</packaging>
  <version>3.0.0.M4</version>
</dependency>

How do you automatically provide an answer to a Unix command for example

cp: overwrite `destination/./b.txt'?

Many Unix/Linux commands that operate on files may stop and ask for confirmation for each file before completing an action. Of course for many Unix/Linux commands there are parameters that allows you to specify the desired behavior, but there are other commands that doesn’t have that capability. Advanced Unix users just look up the “yes” command on how to solve this. Here’s a contrived example where a directory called “destination” contains two files “a.txt” and “b.txt”. We will now copy two files “b.txt” and “c.txt” from a directory called “source”

|-- destination
|   |-- a.txt
|   `-- b.txt
`-- source
 |-- b.txt
 `-- c.txt

We’ll copy the files using the “cp” command

cp source/*.txt destination/.

When we do this we’ll get the following response on the command line where the OS is asking us what it want us to do since one file being copied already exist in the destination directory i.e. “b.txt”

cp: overwrite `destination/./b.txt'?

Unfortunately on Linux the cp command doesn’t have an option to automatically answer this question with a ‘y’ or ‘n’ answer. There’s more than one solution to this problem depending on what you want to do, and one solution is to use the Unix “yes” command. This command will output a string repeatedly until killed. If we want to avoid overwriting any of the files in the destination directory we could use the “yes” command to answer all questions with a no “n”. Below you can see how the “yes” command is used to automatically provide the answer “n” to the “cp” command. Use “man yes” for more information about the “yes” command.

yes n | cp source/*.txt destination/.

This successfully copies all files with the exception of the “b.txt” file which is what we wanted. The “yes” command automatically provided the answer “n” to the “cp” command question whether or not we wanted to overwrite the destination file.

In the case that you mess up when you use the “yes” command for example by typing this:

yes bingo

The “yes” command will output the word “bingo” repeatedly to the screen. You can stop it by typing Control-C or in a different shell type “pgrep yes” which will display the “yes” commands PID (process ID) which you can use to kill the “yes” command by typing “kill <PID>”

pgrep yes

In my case it returned 24940 so I killed it with:

kill 24940

This is a somewhat confusing compilation failure that sometimes happen when you write unit tests using JUnit 4. This is an example code snippet that produces this error (result.getValue() returns an Integer object):

assertEquals(12345, result.getValue());

And when you try to compile your project it produces a compilation error like this:

/projects/myapp/src/test/java/org/myapp/MyTest.java:[88,8] reference to assertEquals is ambiguous, both method assertEquals(double,double) in org.junit.Assert and method assertEquals(java.lang.Object,java.lang.Object) in org.junit.Assert match

Since JUnit offer several methods that are very similar the compiler can not always determine which one to use. In our case we have the number 12345 which is an int and result.getValue() which is an Integer. You’d think that the compiler could figure out to convert the number 12345 to an Integer object which would give us a match on “assertEquals(java.lang.Object, java.lang.Object) method, but instead it throws the above error.

The reason for this is that Java uses best match to try to determine the method that will require the least conversion of the parameters. In this case one method requires boxing, and the other method would require un-boxing. Both of these methods have equal priority and that’s why there is ambiguity since none of the methods are more specific than the other.

The solution is to help the compiler determine what it need to do. We can do that using this:

assertEquals(12345, (int) result.getValue());

or this:

assertEquals((Integer)12345, result.getValue());

to resolve this problem. The second solution that converts 12345 to an Integer object is most likely the better once since Java will auto-box a null value to the number 0 which may not be the correct behavior for the class you’re testing.

If you need to define and end of line character (EOL) like \n in your Spring XML files in a bean property you can’t do this

<bean id="some-bean-id" class="some-class">
    <property name="my-property-name" value="\n"/>
</bean>

This simply wont work. You’ll end up with a backslash followed by the letter n. What you have to do is to use an escape character like this

<bean id="some-bean-id">
    <property name="my-property-name" value="&#10;"/>
</bean>

Log4j version 1.2.15 added features which has new dependencies on sun and javax packages. When you try to build your project using Maven and log4j 1.2.15 you will see this:

[INFO] Unable to find resource 'com.sun.jmx:jmxri:jar:1.2.1' in repository central (http://repo1.maven.org/maven2)
[INFO] Unable to find resource 'com.sun.jdmk:jmxtools:jar:1.2.1' in repository central (http://repo1.maven.org/maven2)
[INFO] Unable to find resource 'javax.jms:jms:jar:1.1' in repository central (http://repo1.maven.org/maven2)

These packages are not in the Maven repositories due to licensing issues. There are two simple solutions to this problem. You can either modify your pom.xml file to use the previous version of log4j (log4j 1.2.14) which doesn’t depend on the JMX and JMS packages:

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.14</version>
</dependency>

Or you can exclude the dependencies with the caveat that some of the lo4gj appenders  that depend on these packages wont be available

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.15</version>
    <exclusions>
        <!--
        These packages are not in the Maven repository
        If you do this certain log4j appenders will not be available
        -->
        <exclusion>
            <groupId>javax.jms</groupId>
            <artifactId>jms</artifactId>
        </exclusion>
        <exclusion>
            <groupId>com.sun.jdmk</groupId>
            <artifactId>jmxtools</artifactId>
        </exclusion>
        <exclusion>
            <groupId>com.sun.jmx</groupId>
            <artifactId>jmxri</artifactId>
        </exclusion>
    </exclusions>
</dependency>

If you get this error message “svn: Inconsistent line ending style” when trying to commit a binary file into your SVN repository then Subversion probably thinks that your file is a text file.

First verify your file with:

svn proplist <your-file>

If the result contains svn:eol-style but you know that your file is a binary file then you have a problem where Subversion thinks the file is a text file even though it’s not. We fix this by first deleting the erroneous properties and then adding the ones we want.

svn propdel svn:eol-style <your-file>

svn propset svn:mime-type application/octet-stream <your-file>

Verify your file again with the command below

svn proplist <your-file>

If everything worked it should say svn:mime-type

You can set environment variables or pass them in using the -Dvariablename syntax

SET logfile=/location/to/my/log/file.log

or

java -Dlogfile=/location/to/my/log/file.log HelloWorld

When you want to access these environment variables from your Java source file you can use

Java 1.5 and newer:

String logfileLocation = System.getenv("logfile");

Java 1.4 and older:

String logfileLocation = System.getProperty("logfile");

I found this very useful web site that allows you to search what JAR file a specific Java class belongs to. This has proven quite useful to me over the last couple of days when I had to deal with NoClassDefFoundError and ClassNotFoundException problems.

You can just enter the name of the class or JAR file your looking for and the site will display the result.

http://www.findjar.com/index.jsp

I’ve used JMock for quite some time and I’ve found it to be a great and very useful mocking framework for unit testing. I was never quite happy with the syntax though; especially the part where you specify expectations.  Here’s a JMock snippet illustrating an expectation and a return value from a mocked object

context.checking(new Expectations() {{
    oneOf (department).employees(); will(returnIterator(employees));
}});

In Mockito the equivalent code would look like this

when(department.employees()).thenReturn(employees);

I find the Mockito syntax to be easier to write and understand. I’ve seen fellow developers implement JMock expectations in a way where they actually didn’t perform a useful test, and I think the sometimes confusing syntax of JMock was the reason. I’m not dismissing JMock as an inferior mocking framework, but I do think that the learning curve is a bit steeper. If you haven’t used Mockito yet I encourage you to take a look at it.

I noticed that I had almost no space left on my MacBook and I couldn’t see a good reason why I would have so little space left. In Windows I used an excellent application called WinDirStat to find out what was wasting space on my harddrive, and I was glad to see that there’s a similar app for OS X called Disk Inventory X. Both of these free and excellent applications  shows you a graphical tree map that makes it easy to see what is using up your disk space. In my case it turned out to be Entourage which due to frequent crashes had led to multiple copies of the Entourage database. I deleted several copies of the database and recovered a lot of space.

Disk Inventory X: http://www.derlien.com/

Location of Entourage files: http://www.entourage.mvps.org/path/index.html#ent_db