Spring Batch in Action

Spring Batch in Action is an in-depth guide to writing batch applications using Spring Batch. Written for developers who have basic knowledge of Java and the Spring lightweight container, the book provides both a best-practices approach to writing batch jobs and comprehensive coverage of the Spring Batch framework.

The book is available directly from Manning, and from the usual on-line booksellers Amazon, Barnes & Noble, Powell’s Books and Walmart!

And in the UK, from Pearson.

@ClassRule fill a gap in the JUnit API, by providing class level rules like @BeforeClass and @AfterClass provide class wide set up and tear down.

This article explains how to control code execution of unit tests and where @ClassRule fits in.

The terminology I use:

• A test implements @Test
• A test case in a class with @Test methods

Ordering test methods

The simplest test case you can write in JUnit is to annotate methods with @Test:

package test;

import org.junit.Test;

public class OrderTest1 {

    @Test
    public void test1() {
        println("@Test test1()");
    }

    @Test
    public void test2() {
        println("@Test test2()");
    }

    private void println(String string) {
        OrderTestUtils.println(OrderTest1.class, string);
    }
}

In OrderTest1, the execution order is:

OrderTest1 @Test test1()
OrderTest1 @Test test2()

Managing test fixtures

If you need to initialize the same data for each test, you put that data in instance variables and initialize them in a @Before setUp method. The setUp method is called before each @Test method.

One test invocation becomes the following call sequence:

1. Call @Before setUp
2. Call one @Test method

If that data needs to be cleaned up, implement an @After tearDown method. The tearDown method is called after each @Test method.

One test invocation becomes the following call sequence:

1. Call @Before setUp
2. Call one @Test method
3. Call @After tearDown

The call sequence for a class with two test methods is:

1. Call @Before setUp
2. Call @Test method test1
3. Call @After tearDown
4. Call @Before setUp
5. Call @Test method test2
6. Call @After tearDown

For example:

package test;

import java.io.Closeable;
import java.io.IOException;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;

public class OrderTest2 {

    static class ManagedResource implements Closeable {
        @Override
        public void close() throws IOException {
        }
    }

    private ManagedResource managedResource;

    private void println(String string) {
        OrderTestUtils.println(OrderTest2.class, string);
    }

    @Before
    public void setUp() {
        this.println("@Before setUp");
        this.managedResource = new ManagedResource();
    }

    @After
    public void tearDown() throws IOException {
        this.println("@After tearDown");
        this.managedResource.close();
        this.managedResource = null;
    }

    @Test
    public void test1() {
        this.println("@Test test1()");
    }

    @Test
    public void test2() {
        this.println("@Test test2()");
    }
}

In OrderTest2, the execution order is:

OrderTest2 @Before setUp
OrderTest2 @Test test1()
OrderTest2 @After tearDown
OrderTest2 @Before setUp
OrderTest2 @Test test2()
OrderTest2 @After tearDown

Managing expensive test fixtures

When a resource is expensive to manage like a connection to a server, a database, or even managing an embedded server, it’s best to only initialize that resource once for the whole test case. You want to avoid starting and stopping a server for each @Test method. Instead you want to initialize once for all the tests in the class.

To do so, we a @BeforeClass and @AfterClass methods, instead of @Before and @After to get the following call sequence:

1. Call @BeforeClass setUpClass
2. Call @Test method test1
3. Call @Test method test2
4. Call @AfterClass tearDownClass

Let’s add class-level set up and tear down to our example:

package test;

import java.io.Closeable;
import java.io.IOException;

import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;

public class OrderTest3 {

    static class ExpensiveManagedResource implements Closeable {
        @Override
        public void close() throws IOException {
        }
    }

    static class ManagedResource implements Closeable {
        @Override
        public void close() throws IOException {
        }
    }

    @BeforeClass
    public static void setUpClass() {
        OrderTestUtils.println(OrderTest3.class, "@BeforeClass setUpClass");
        MyExpensiveManagedResource = new ExpensiveManagedResource();
    }

    @AfterClass
    public static void tearDownClass() throws IOException {
        OrderTestUtils.println(OrderTest3.class, "@AfterClass tearDownClass");
        MyExpensiveManagedResource.close();
        MyExpensiveManagedResource = null;
    }

    private ManagedResource myManagedResource;
    private static ExpensiveManagedResource MyExpensiveManagedResource;

    private void println(String string) {
        OrderTestUtils.println(OrderTest3.class, string);
    }

    @Before
    public void setUp() {
        this.println("@Before setUp");
        this.myManagedResource = new ManagedResource();
    }

    @After
    public void tearDown() throws IOException {
        this.println("@After setUp");
        this.myManagedResource.close();
        this.myManagedResource = null;
    }

    @Test
    public void test1() {
        this.println("@Test test1()");
    }

    @Test
    public void test2() {
        this.println("@Test test2()");
    }
}

In OrderTest3, the execution order is:

OrderTestAll @BeforeClass setUpClass
OrderTestAll @Before setUp
OrderTestAll @Test test1()
OrderTestAll @After setUp
OrderTestAll @Before setUp
OrderTestAll @Test test2()
OrderTestAll @After setUp
OrderTestAll @AfterClass tearDownClass

You can see that the setUpClass and tearDownClass wrap the execution of this test case.

Managing resources with rules

Instead of duplicating resource management code in each class, you can reuse your code, but instead of putting this common in a superclass for all your tests. you can abstract external resource management with a JUnit Rule.

JUnit  rules are subclasses of the ExternalResource class.

Let’s do it both ways and compare.

package test;

import java.io.Closeable;
import java.io.IOException;

import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.ExternalResource;

public class OrderTest4 {

    static class ExpensiveExternalResource extends ExternalResource {

        ExpensiveExternalResource() {
            OrderTestUtils.println(ExpensiveExternalResource.class, "constructor");
        }

        @Override
        protected void after() {
            OrderTestUtils.println(ExpensiveExternalResource.class, "after");
        };

        @Override
        protected void before() throws Throwable {
            OrderTestUtils.println(ExpensiveExternalResource.class, "before");
        };
    };

    static class ExpensiveManagedResource implements Closeable {
        @Override
        public void close() throws IOException {
        }
    }

    static class ManagedResource implements Closeable {
        @Override
        public void close() throws IOException {
        }
    }

    @BeforeClass
    public static void setUpClass() {
        OrderTestUtils.println(OrderTest4.class, "@BeforeClass setUpClass");
        MyExpensiveManagedResource = new ExpensiveManagedResource();
    }

    @AfterClass
    public static void tearDownClass() throws IOException {
        OrderTestUtils.println(OrderTest4.class, "@AfterClass tearDownClass");
        MyExpensiveManagedResource.close();
        MyExpensiveManagedResource = null;
    }

    @Rule
    public ExternalResource resource = new ExpensiveExternalResource();

    private ManagedResource myManagedResource;

    private static ExpensiveManagedResource MyExpensiveManagedResource;

    private void println(String string) {
        OrderTestUtils.println(OrderTest4.class, string);
    }

    @Before
    public void setUp() {
        this.println("@Before setUp");
        this.myManagedResource = new ManagedResource();
    }

    @After
    public void tearDown() throws IOException {
        this.println("@After tearDown()");
        this.myManagedResource.close();
        this.myManagedResource = null;
    }

    @Test
    public void test1() {
        this.println("@Test test1()");
    }

    @Test
    public void test2() {
        this.println("@Test test2()");
    }
}

The method are run in the following order:

OrderTest4 @BeforeClass setUpClass
ExpensiveExternalResource constructor
ExpensiveExternalResource before
OrderTest4 @Before setUp
OrderTest4 @Test test1()
OrderTest4 @After setUp
ExpensiveExternalResource after
ExpensiveExternalResource constructor
ExpensiveExternalResource before
OrderTest4 @Before setUp
OrderTest4 @Test test2()
OrderTest4 @After setUp
ExpensiveExternalResource after
OrderTest4 @AfterClass tearDownClass

The ExternalResource before method is called just before the @Before setUp method.

The ExternalResource after method is called just before the @After setUp method.

An ExternalResource is a nice way to abstract out and resuse your resource management code. You can now compose use of your resources instead of  subclassing.

Managing expensive resources with rules

Just like you can wrap a test case with @BeforeClass and @AfterClass, there was no way to do this with rules until JUnit 4.9 and the ClassRule annotation.

The following examples shows a ClassRule at work. Deltas from the previous example are highlighted.

package test;

import java.io.Closeable;
import java.io.IOException;

import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.ClassRule;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.ExternalResource;

public class OrderTest5 {

    static class ExpensiveExternalResource extends ExternalResource {

        private final String info;

        ExpensiveExternalResource(String info) {
            this.info = info;
            OrderTestUtils.println(ExpensiveExternalResource.class, "constructor " + info);
        }

        @Override
        protected void after() {
            OrderTestUtils.println(ExpensiveExternalResource.class, "after " + this.info);
        };

        @Override
        protected void before() throws Throwable {
            OrderTestUtils.println(ExpensiveExternalResource.class, "before " + this.info);
        };
    };

    static class ExpensiveManagedResource implements Closeable {
        @Override
        public void close() throws IOException {
        }
    }

    static class ManagedResource implements Closeable {
        @Override
        public void close() throws IOException {
        }
    }

    @BeforeClass
    public static void setUpClass() {
        OrderTestUtils.println(OrderTest5.class, "@BeforeClass setUpClass");
        MyExpensiveManagedResource = new ExpensiveManagedResource();
    }

    @AfterClass
    public static void tearDownClass() throws IOException {
        OrderTestUtils.println(OrderTest5.class, "@AfterClass tearDownClass");
        MyExpensiveManagedResource.close();
        MyExpensiveManagedResource = null;
    }

    @Rule
    public ExternalResource resource = new ExpensiveExternalResource("instance");

    @ClassRule
    public static ExternalResource StaticResource = new ExpensiveExternalResource("static");

    private ManagedResource myManagedResource;

    private static ExpensiveManagedResource MyExpensiveManagedResource;

    private void println(String string) {
        OrderTestUtils.println(OrderTest5.class, string);
    }

    @Before
    public void setUp() {
        this.println("@Before setUp");
        this.myManagedResource = new ManagedResource();
    }

    @After
    public void tearDown() throws IOException {
        this.println("@After tearDown()");
        this.myManagedResource.close();
        this.myManagedResource = null;
    }

    @Test
    public void test1() {
        this.println("@Test test1()");
    }

    @Test
    public void test2() {
        this.println("@Test test2()");
    }
}

The test run shows the ClassRule kick in at the start and end of the test case:

ExpensiveExternalResource constructor static
ExpensiveExternalResource before static
OrderTest5 @BeforeClass setUpClass
ExpensiveExternalResource constructor instance
ExpensiveExternalResource before instance
OrderTest5 @Before setUp
OrderTest5 @Test test1()
OrderTest5 @After tearDown()
ExpensiveExternalResource after instance
ExpensiveExternalResource constructor instance
ExpensiveExternalResource before instance
OrderTest5 @Before setUp
OrderTest5 @Test test2()
OrderTest5 @After tearDown()
ExpensiveExternalResource after instance
OrderTest5 @AfterClass tearDownClass
ExpensiveExternalResource after static

Subclassing test cases

What happens when you subclass a test case? For example:

package test;

import org.junit.Test;

public class SubOrderTest1 extends OrderTest1 {

    private void println(String string) {
        OrderTestUtils.println(SubOrderTest1.class, string);
    }

    @Test
    public void testSub1() {
        this.println("@Test testSub1()");
    }

    @Test
    public void testSub2() {
        this.println("@Test testSub1()");
    }
}

JUnit runs the given test case and then the super class test case:

SubOrderTest1 @Test testSub1()
SubOrderTest1 @Test testSub1()
OrderTest1 @Test test1()
OrderTest1 @Test test2()

If you add a third level with a SubSubOrderTest1 class extending SubOrderTest1, you get:

SubSubOrderTest1 @Test testSubSub1()
SubSubOrderTest1 @Test testSubSub1()
SubOrderTest1 @Test testSub1()
SubOrderTest1 @Test testSub1()
OrderTest1 @Test test1()
OrderTest1 @Test test2()

Method execution order starts with the given test case and goes up the super class chain until you get to the top of the hierarchy.

Subclassing test cases with managed resources

Here, things get trickier.

The order of @Before methods goes from the top to the bottom of the hierarchy: parent, child, child of child.

The order of @After methods goes from the bottom to the top of the hierarchy: child of child, child, parent.

For example:

package test;

import java.io.Closeable;
import java.io.IOException;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;

public class SubOrderTest2 extends OrderTest2 {

    static class ManagedResource implements Closeable {
        @Override
        public void close() throws IOException {
        }
    }

    private ManagedResource managedResource;

    private void println(String string) {
        OrderTestUtils.println(SubOrderTest2.class, string);
    }

    @Before
    public void setUpSub() {
        this.println("@Before setUpSub");
        this.managedResource = new ManagedResource();
    }

    @After
    public void tearDownSub() throws IOException {
        this.println("@After tearDownSub");
        this.managedResource.close();
        this.managedResource = null;
    }

    @Test
    public void testSub1() {
        this.println("@Test testSub1()");
    }

    @Test
    public void testSub2() {
        this.println("@Test testSub2()");
    }
}

Here, JUnit runs the given test case and then the super class test case:

OrderTest2 @Before setUp
SubOrderTest2 @Before setUpSub
SubOrderTest2 @Test testSub1()
SubOrderTest2 @After tearDownSub
OrderTest2 @After tearDown
OrderTest2 @Before setUp
SubOrderTest2 @Before setUpSub
SubOrderTest2 @Test testSub2()
SubOrderTest2 @After tearDownSub
OrderTest2 @After tearDown
OrderTest2 @Before setUp
SubOrderTest2 @Before setUpSub
OrderTest2 @Test test1()
SubOrderTest2 @After tearDownSub
OrderTest2 @After tearDown
OrderTest2 @Before setUp
SubOrderTest2 @Before setUpSub
OrderTest2 @Test test2()
SubOrderTest2 @After tearDownSub
OrderTest2 @After tearDown

If add a third level with a SubSubOrderTest2 class extending SubOrderTest2, you get:

OrderTest2 @Before setUp
SubOrderTest2 @Before setUpSub
SubSubOrderTest2 @Before setUpSubSub
SubSubOrderTest2 @Test testSubSub1()
SubSubOrderTest2 @After tearDownSubSub
SubOrderTest2 @After tearDownSub
OrderTest2 @After tearDown
OrderTest2 @Before setUp
SubOrderTest2 @Before setUpSub
SubSubOrderTest2 @Before setUpSubSub
SubSubOrderTest2 @Test testSubSub2()
SubSubOrderTest2 @After tearDownSubSub
SubOrderTest2 @After tearDownSub
OrderTest2 @After tearDown
OrderTest2 @Before setUp
SubOrderTest2 @Before setUpSub
SubSubOrderTest2 @Before setUpSubSub
SubOrderTest2 @Test testSub1()
SubSubOrderTest2 @After tearDownSubSub
SubOrderTest2 @After tearDownSub
OrderTest2 @After tearDown
OrderTest2 @Before setUp
SubOrderTest2 @Before setUpSub
SubSubOrderTest2 @Before setUpSubSub
SubOrderTest2 @Test testSub2()
SubSubOrderTest2 @After tearDownSubSub
SubOrderTest2 @After tearDownSub
OrderTest2 @After tearDown
OrderTest2 @Before setUp
SubOrderTest2 @Before setUpSub
SubSubOrderTest2 @Before setUpSubSub
OrderTest2 @Test test1()
SubSubOrderTest2 @After tearDownSubSub
SubOrderTest2 @After tearDownSub
OrderTest2 @After tearDown
OrderTest2 @Before setUp
SubOrderTest2 @Before setUpSub
SubSubOrderTest2 @Before setUpSubSub
OrderTest2 @Test test2()
SubSubOrderTest2 @After tearDownSubSub
SubOrderTest2 @After tearDownSub
OrderTest2 @After tearDown

I hope you found this post helpful. I was a nice reminder for me to lay it out and remember the power of JUnit rules. With the new ClassRule in JUnit 4.9, rules can finally be used at full strength.

It appears my wish has been answered with the release of JUnit 4.9 and the new @ClassRule annotation.

The only change required to make our example work is to replace @Rule with @ClassRule:

package test;

import java.io.File;
import java.io.IOException;

import junit.framework.Assert;

import org.junit.BeforeClass;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.TemporaryFolder;

public class TemporaryFolderRuleBeforeClass {
    @ClassRule
    public static TemporaryFolder testFolder = new TemporaryFolder();

    @BeforeClass
    public static void testInTempFolder() throws IOException {
        File tempFile = testFolder.newFile("file.txt");
        File tempFolder = testFolder.newFolder("folder");
        System.out.println("Test folder: " + testFolder.getRoot());
        // test
        Assert.assertNotNull(testFolder.getRoot());
    }

    @Test
    public void test() {
        // ...
    }
}

Voila! It just works, the @ClassRule is set up correctly before the @BeforeClass method is called. Thank you JUnit 4.9!

Let’s take a brain dead ID generator as our domain object example:

    /**
     * Generates sequential unique IDs starting with 1, 2, 3, and so on.
     * <p>
     * This class is NOT thread-safe.
     * </p>
     */
    static class BrokenUniqueIdGenerator {
        private long counter = 0;

        public long nextId() {
            return ++counter;
        }
    }

This is how you test this class with different threads loads of 1, 2, 4, 8, 16, and 32 threads. We use the Java java.util.concurrent API to manage threads to use our domain object concurrently. We use JUnit @Test methods to run the test and verify results.

    @Test
    public void test01() throws InterruptedException, ExecutionException {
        test(1);
    }

    @Test
    public void test02() throws InterruptedException, ExecutionException {
        test(2);
    }

    @Test
    public void test04() throws InterruptedException, ExecutionException {
        test(4);
    }

    @Test
    public void test08() throws InterruptedException, ExecutionException {
        test(8);
    }

    @Test
    public void test16() throws InterruptedException, ExecutionException {
        test(16);
    }

    @Test
    public void test32() throws InterruptedException, ExecutionException {
        test(32);
    }

    private void test(final int threadCount) throws InterruptedException, ExecutionException {
        final BrokenUniqueIdGenerator domainObject = new BrokenUniqueIdGenerator();
        Callable<Long> task = new Callable<Long>() {
            @Override
            public Long call() {
                return domainObject.nextId();
            }
        };
        List<Callable<Long>> tasks = Collections.nCopies(threadCount, task);
        ExecutorService executorService = Executors.newFixedThreadPool(threadCount);
        List<Future<Long>> futures = executorService.invokeAll(tasks);
        List<Long> resultList = new ArrayList<Long>(futures.size());
        // Check for exceptions
        for (Future<Long> future : futures) {
            // Throws an exception if an exception was thrown by the task.
            resultList.add(future.get());
        }
        // Validate the IDs
        Assert.assertEquals(futures.size(), threadCount);
        List<Long> expectedList = new ArrayList<Long>(threadCount);
        for (long i = 1; i <= threadCount; i++) {
            expectedList.add(i);
        }
        Collections.sort(resultList);
        Assert.assertEquals(expectedList, resultList);
    }

Let’s walk through the test(int threadCount) method. We start by creating our domain object:

final BrokenUniqueIdGenerator domainObject = new BrokenUniqueIdGenerator();

This class has one method, nextId, which we wrap into a task, an instance of Callable:

        Callable<Long> task = new Callable<Long>() {
            @Override
            public Long call() {
                return domainObject.nextId();
            }
        };

This is just a generic way to fit our API call in the Java concurrency API.

We then make copies of this task, one for each thread:

List<Callable<Long>> tasks = Collections.nCopies(threadCount, task);

Next, we create a thread pool, sized at least as big as the number of threads we want to test, in this case we use the exact given value threadCount.

ExecutorService executorService = Executors.newFixedThreadPool(threadCount);

And ask Java to run all the tasks concurrently using threads from the pool:

List<Future<Long>> futures = executorService.invokeAll(tasks);

The call to invokeAll blocks until all the threads are done. Each task is run on a thread, which invokes the tasks’ call method, which in turn calls our domain object API, nextId().

When you run this test case, it will sometimes pass and sometimes fail.

That’s multithreaded testing with Java 5 and JUnit 4. Voila!

BTW, the proper implementation is:

    /**
     * Generates sequential unique IDs starting with 1, 2, 3, and so on.
     * <p>
     * This class is thread-safe.
     * </p>
     */
    static class UniqueIdGenerator {
        private final AtomicLong counter = new AtomicLong();

        public long nextId() {
            return counter.incrementAndGet();
        }
    }

The full listing is:

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.atomic.AtomicLong;

import org.junit.Assert;
import org.junit.Test;

public class MultiThreadedTestCase {

    /**
     * Generates sequential unique IDs starting with 1, 2, 3, and so on.
     * <p>
     * This class is NOT thread-safe.
     * </p>
     */
    static class BrokenUniqueIdGenerator {
        private long counter = 0;

        public long nextId() {
            return ++counter;
        }
    }

    /**
     * Generates sequential unique IDs starting with 1, 2, 3, and so on.
     * <p>
     * This class is thread-safe.
     * </p>
     */
    static class UniqueIdGenerator {
        private final AtomicLong counter = new AtomicLong();

        public long nextId() {
            return counter.incrementAndGet();
        }
    }

    private void test(final int threadCount) throws InterruptedException, ExecutionException {
        final UniqueIdGenerator domainObject = new UniqueIdGenerator();
        Callable<Long> task = new Callable<Long>() {
            @Override
            public Long call() {
                return domainObject.nextId();
            }
        };
        List<Callable<Long>> tasks = Collections.nCopies(threadCount, task);
        ExecutorService executorService = Executors.newFixedThreadPool(threadCount);
        List<Future<Long>> futures = executorService.invokeAll(tasks);
        List<Long> resultList = new ArrayList<Long>(futures.size());
        // Check for exceptions
        for (Future<Long> future : futures) {
            // Throws an exception if an exception was thrown by the task.
            resultList.add(future.get());
        }
        // Validate the IDs
        Assert.assertEquals(futures.size(), threadCount);
        List<Long> expectedList = new ArrayList<Long>(threadCount);
        for (long i = 1; i <= threadCount; i++) {
            expectedList.add(i);
        }
        Collections.sort(resultList);
        Assert.assertEquals(expectedList, resultList);
    }

    @Test
    public void test01() throws InterruptedException, ExecutionException {
        test(1);
    }

    @Test
    public void test02() throws InterruptedException, ExecutionException {
        test(2);
    }

    @Test
    public void test04() throws InterruptedException, ExecutionException {
        test(4);
    }

    @Test
    public void test08() throws InterruptedException, ExecutionException {
        test(8);
    }

    @Test
    public void test16() throws InterruptedException, ExecutionException {
        test(16);
    }

    @Test
    public void test32() throws InterruptedException, ExecutionException {
        test(32);
    }
}

Note: I used Oracle Java 1.6.0_24 (64-bit) on Windows 7 (64-bit).

@Test
@Ignore
public void testAdd() {
   ...
}

What if you want to only ignore the test under a condition determined at runtime? This would be nice:

@Test
@Ignore(someCondition())
public void testAdd() {
   ...
}

@Test
public void testAdd() {
   Assume.assumeTrue(someCondition());
   ...
}

Like in botany, trunk is a tree’s central superstructure. All branches come out of the trunk:

Trunk and branches from http://www.javaworld.com/javaworld/jw-01-2008/images/svn1.jpg

Main development is performed in the trunk. Releases are branched for bug fixes and maintenance releases.

In the next diagram, the tip of the arrows for trunk and a branches are HEADs. Each branch and trunk have a HEAD.

Heads on trunk and branches from http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.using

That’s it!

Integer.MAX_VALUE =  2147483647
Integer.MIN_VALUE = -2147483648

Long.MAX_VALUE =  9223372036854775807
Long.MIN_VALUE = -9223372036854775808

Does that work?

No.

You need to:

• Grant permission for the directory to the IIS group IIS_IUSRS.
• In the IIS Manager, in Authentication/Anonymous Authentication, change the setting to “Application pool identity”

Then you can get IIS to serve you files locally.

java.lang.IllegalStateException: Unable to create JAXBContext for generated packages: "appinterface.seagullsw.com.appinterfaceserver" doesnt contain ObjectFactory.class or jaxb.index
  at org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:343)
  at org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:196)
  at org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:175)
  at com.seagullsw.appinterface.server.comm.soap.SoapCmCxfTests.testWssAll(SoapCmCxfTests.java:354)
Caused by: javax.xml.bind.JAXBException: "appinterface.seagullsw.com.appinterfaceserver" doesnt contain ObjectFactory.class or jaxb.index
  at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:197)
  at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:128)
  at javax.xml.bind.ContextFinder.find(ContextFinder.java:277)
  at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:372)
  at org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:340)

We use CXF 2.2.7 and JAXB 2.2 but this also applies for older versions of CXF and JAXB.

The solution is to add the JDK bin directory to your execution path (PATH on Windows), something like:

set PATH=%PATH%;%JAVA_HOME%\bin

where JAVA_HOME points to your JDK root directory.

Now all tests pass from Eclipse and Ant.