Category Archives: Uncategorized

How we handle binary compatibility at Apache Commons

undefined

As a maintainer of the free and open source software project Apache Commons, I review pull requests on GitHub. Since the libraries we produce in components like Commons Lang, Commons IO, and Commons VFS are used directly and transitively in countless applications, open and closed source alike, we want to be careful when releasing new versions to cause the least headaches as possible. One way to enforce our least-headache policy is a recurring reason PRs are rejected: The PR breaks binary compatibility. I’ll outline here how we deal with this issue while still allowing our APIs to evolve.

What is binary compatibility?

Maintaining binary compatibility, in a nutshell, is the ability to drop a new version of a class file (in a jar for example) on top of your application and have it run without the Java Virtual Machine throwing an error trying to call the updated code.

At the JLS level, this means binary compatibility is preserved when a binary that previously linked without error continues to link without error.

Binary compatibility is… well, a binary quality: A release either is or isn’t binary compatible with its previous version.

If you remove a class or method and your app tries to call it, you break binary compatibility and your app blows up.

If you add or remove a parameter to a method, you break binary compatibility and, your app blows up.

This is all detailed in the Java Language Specification.

Note that this is different from source compatibility and behavioral compatibility.

Benefiting from binary compatibility

Why do this? To avoid Jar hell and needlessly breaking applications. See also DLL hell.

Defining guidelines at Apache Commons

Our guideline at Apache Commons on binary compatibility is:

Don’t break binary compatibility in a minor release (e.g. 2.0 to 2.1) or a maintenance release (e.g. 2.1.2 to 2.1.3).

For a major release (e.g. 2.2 to 3.0), you may break binary compatibility; and if you do, you must change the Java package name and Maven coordinate’s artifact ID.

For example, when Apache Commons Lang 3.0 was released, we updated the Java package from org.apache.commons.lang to org.apache.commons.lang3 and the Maven artifact ID from commons-lang to commons-lang3.

In the case of Apache Commons Lang, the 1.x and 2.x series of releases live in the same package and Maven coordinates.

This system allows, and this is key, for version 2 and 3 to co-exist in the same class loader. While the same is true for version 1 and 3, it is not for 1 and 2.

What am I allowed to change?

Almost everything, according to the Java Language Specification, you may:

  • Rewrite the body of methods, constructors, and initializers (like static blocks).
  • Rewrite code in the above that previously threw exceptions to no longer do so.
  • Add fields, methods, and constructors.
  • Delete items declared private.
  • Reorder fields, methods, and constructors.
  • Move a method higher in a class hierarchy.
  • Reorder the list of direct super-interfaces in a class or interface.
  • Insert new class or interface types in a type hierarchy.
  • Add generics (since the compiler erases them).

In addition, our guidelines allow for updating package private element.

Checking for binary compatibility

When a release candidate is put up for a vote, it is proposed along with a web site generated by Maven which contains a report on binary compatibility. There are several tools you can use to do this, we usually use the JApiCmp Maven plugin. For example, this is the report for the current version of Apache Commons Lang.

A pattern I like using is providing a default Maven goal which includes JApiCmp which I invoke for builds on Travis-CI and GitHub Actions. For example:

<defaultGoal>clean verify apache-rat:check japicmp:cmp checkstyle:check spotbugs:check javadoc:javadoc</defaultGoal>

Wrapping up

All of this to say, as a library author:

  • Don’t give your users headaches or put their apps in Jar hell by maintaining binary compatibility within a major release line.
  • Use a build tool to fail a build that breaks binary compatibility.
  • When you must break binary compatibility, change the Java package name and Maven coordinates (this works for Ivy, Gradle, and so on).

Explaining Terms at Apache

At Apache, the term project refers to a whole top level project (TLP).

Apache Commons is a TLP.

Apache Commons is made up of over 20 components.

Apache Commons components produce one or or more jar files. The components are listed on the Commons’ project main page.

Apache Commons CSV releases version 1.2

logo-apache-commons-csvThe Apache Commons CSV team is pleased to announce the 1.2 release!

The Apache Commons CSV library provides a simple interface for reading and writing CSV files of various types.

This is our third release.

Apache Commons CSV requires at least Java 6.

This is a minor feature and bug fix release.

Changes in this version include:

New Features

  • CSV-157: Add enum CSVFormat.Predefined that contains the default CSVFormat values.

Fixed Bugs

  • CSV-145: CSVFormat.with* methods clear the header comments. Thanks to Frank Ulbricht.
  • CSV-156: Incorrect Javadoc on QuoteMode.NONE. Thanks to Jason Steenstra-Pickens.

Historical list of changes: http://commons.apache.org/proper/commons-csv/changes-report.html

For complete information on Apache Commons CSV, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons CSV website.

Happy Coding!
Gary Gregory on behalf of the Apache Commons CSV team

You can also subscribe to announce@apache.org announcements.

ApacheCon 2015 in Austin, Texas

Dear Apache enthusiasts,

In just a few weeks, we’ll be holding ApacheCon in Austin, Texas, and we’d love to have you in attendance. You can save $300 on admission by registering NOW, since the early bird price ends on the 21st.

Register at http://s.apache.org/acna2015-reg

ApacheCon this year celebrates the 20th birthday of the Apache HTTP Server, and we’ll have Brian Behlendorf, who started this whole thing, keynoting for us, and you’ll have a chance to meet some of the original Apache Group, who will be there to celebrate with us.

We’ve got 7 tracks of great talks, as well as BOFs, the Apache BarCamp, project-specific hack events, and evening events where you can deepen your connection with the larger Apache community. See the full schedule athttp://apacheconna2015.sched.org/

And if you have any questions, comments, or just want to hang out with us before and during the event, follow us on Twitter – @apachecon – or drop by #apachecon on the Freenode IRC network.

Hope to see you in Austin!

Understanding JUnit method order execution (updated for version 4.11)

a-zI’m revisiting my post Understanding JUnit method order execution to discuss how to fix tests that depend on method order by using JUnit 4.11.

Let’s start with a rule: You should not create test methods that depend on the order in which they are executed.

If you do have such tests and they are failing randomly or rarely, this is why: JUnit relies on Java’s reflection API to get which test methods to execute. The problem is that the API does not define the order of the methods it returns. Your tests may work for a long time and then fail, apparently randomly. The things is, you’ve just been lucky all along and relying on the Java run-time giving you a consistent answer when it makes no such guarantee.

You may even see some very confusing behavior like a superclass’ test methods being mixed in with its subclass. I’ve seen this in Eclipse and Ant for example.

JUnit 4.11 provides a workarounds for this behavior with a new class-level annotation: FixMethodOrder(MethodSorters.NAME_ASCENDING). For example:

 @FixMethodOrder(MethodSorters.NAME_ASCENDING)
 public class MyTestCase { ... }
 

The annotation FixMethodOrder sorts the test methods in lexicographic method name order, and uses Method#toString() to break ties.

The recipe is: (1) Use @FixMethodOrder, (2) Fix your tests, (3) Remove @FixMethodOrder.

JUnit is available from GitHub.

Understanding JUnit method order execution

[Note this additional post on this topic]

With the addition of the ClassRule annotation in JUnit 4.9, I thought I’d come back and revisit JUnit test order execution.

@ClassRule fills 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(&quot;@Test test1()&quot;);
    }

    @Test
    public void test2() {
        println(&quot;@Test test2()&quot;);
    }

    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(&quot;@Before setUp&quot;);
        this.managedResource = new ManagedResource();
    }

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

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

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

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, initialize the server once for all the tests in the class.

To do so, we use @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, &quot;@BeforeClass setUpClass&quot;);
        MyExpensiveManagedResource = new ExpensiveManagedResource();
    }

    @AfterClass
    public static void tearDownClass() throws IOException {
        OrderTestUtils.println(OrderTest3.class, &quot;@AfterClass tearDownClass&quot;);
        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(&quot;@Before setUp&quot;);
        this.myManagedResource = new ManagedResource();
    }

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

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

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

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 code 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, &quot;constructor&quot;);
        }

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

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

    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, &quot;@BeforeClass setUpClass&quot;);
        MyExpensiveManagedResource = new ExpensiveManagedResource();
    }

    @AfterClass
    public static void tearDownClass() throws IOException {
        OrderTestUtils.println(OrderTest4.class, &quot;@AfterClass tearDownClass&quot;);
        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(&quot;@Before setUp&quot;);
        this.myManagedResource = new ManagedResource();
    }

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

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

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

The methods 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, &quot;constructor &quot; + info);
        }

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

        @Override
        protected void before() throws Throwable {
            OrderTestUtils.println(ExpensiveExternalResource.class, &quot;before &quot; + 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, &quot;@BeforeClass setUpClass&quot;);
        MyExpensiveManagedResource = new ExpensiveManagedResource();
    }

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

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

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

    private ManagedResource myManagedResource;

    private static ExpensiveManagedResource MyExpensiveManagedResource;

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

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

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

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

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

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(&quot;@Test testSub1()&quot;);
    }

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

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(&quot;@Before setUpSub&quot;);
        this.managedResource = new ManagedResource();
    }

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

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

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

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 you 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 full strength.

[Note this additional post on this topic.]

Firefox 4 on Windows 7 Installation Madness

After pulling my hair out trying to install Firefox 4 on Windows 7, I found a solution to the installer disappearing after extracting files. Right-click on the installer and choose Run as administrator. This is not the same, apparently, as selecting the administrator account in the pop up dialog or choosing your account if it happens to be an administrator account, which mine is. Nope, Run as administrator it must be.

A simple IIS 7 test set up should be simple

For simple tests, I want to publish a local directory “dir” through IIS 7 as a virtual directory “vdir” and point my browser to http://localhost/vdir/myfile.xml.

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.

Fixing CXF java.lang.IllegalStateException: Unable to create JAXBContext for generated packages

Our CXF client-server tests passed in Eclispe (3.6M6) but failed when invoked from the command line with Ant 1.7.1. This stack trace is a typical example:

java.lang.IllegalStateException: Unable to create JAXBContext for generated packages: &quot;appinterface.seagullsw.com.appinterfaceserver&quot; 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: &quot;appinterface.seagullsw.com.appinterfaceserver&quot; 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.