Nested unmarshalling can lead to NullPointerException

[glassfishrobot]

The attached ZIP contains a Maven project with two test cases.
For this issue, the classes, resources and test case in package com.jaxbtest.java7.bug2 are relevant.

To reproduce:
1.) make sure your current test environment is Java 7 Update 10
For Maven 2.2.1 on Windows it means:
a) set the JAVA_HOME variable to your Java 7 Update 10 JDK installation directory.
b) prepend %JAVA_HOME%\bin to your Path.
2.) run the unit tests in the project
For Maven 2.2.1 it means:
a) execute "mvn test" in the project root directory
b) examine test result (look at ./target/surefire-reports/com.jaxbtest.java7.bug2.UnternehmenTestCase.txt)

It should fail with a NullPointerException.
Coordinator._getInstance() returns null at some point in the stacktrace, so the error reporting fails too.
You have to debug the test in an IDE to see the real cause. You can import the project into Eclipse (m2e required!) for that.

Some observations about the error cause:
Class Unternehmen is the XmlRootElement. It has a list of Branche-elements, which are handled by the BrancheXmlAdapter.
During unmarshall the adapter uses a BrancheConverter helper class. This class in turn loads a XML document via JAXB.
So we have a nested unmarshalling scenario in the same thread. When the nested umnmarshalling ends, Coordinator.resetThreadAffinity() is called. Later, when the second Branche is unmarshalled from the adapted list of Unternehmen, Coordinator._getInstance() returns null in
AdaptedLister#getAdapter()

com.jaxbtest.java7.bug2.UnternehmenTestCase is the entrypoint for the test.

I think it also fails for JAXB 2.2.6.
It works with Java 6 Update 35 for example.

Environment

Java 7 Update 10 on Windows 7

Affected Versions

[2.2.4u2]

[glassfishrobot]

Reported by brands

[glassfishrobot]

Was assigned to yaroska

[glassfishrobot]

brands said:
How can I attach the ZIP file with the test???

[glassfishrobot]

brands said:
Attachement is available here:
http://glassfish.10926.n7.nabble.com/attachment/87486/0/jaxb-testcases.zip

[glassfishrobot]

ratoo said:
May be related to #844 fix

[glassfishrobot]

anujshahwork said:
We've seen this problem as well. A possible fix that worked for us is to move the ThreadLocal removal logic from resetThreadAffinity() into the popCoordinator() method so that last leaver clears the table.

/**
     * Associates this {@link Coordinator} with the current thread.
     * Should be called at the very beginning of the episode.
     */
    protected final void setThreadAffinity() {
        table = activeTable.get();
        assert table!=null;
    }

    /**
     * Dis-associate this {@link Coordinator} with the current thread.
     * Sohuld be called at the end of the episode to avoid memory leak.
     */
    protected final void resetThreadAffinity() {
        // Don't remove the thread local activeTable here as we may be in a nested serialization situation
        if(debugTableNPE)
            guyWhoSetTheTableToNull = new Exception(); // remember that we set it to null 
        table = null;
    }

    /**
     * Called whenever an execution flow enters the realm of this {@link Coordinator}.
     */
    protected final void pushCoordinator() {
        old = table[0];
        table[0] = this;
    }

    /**
     * Called whenever an execution flow exits the realm of this {@link Coordinator}.
     */
    protected final void popCoordinator() {
        assert table[0]==this;
        table[0] = old;
        if (old == null) {
          // If the old Coordinator is null we must be the last one out of the stack.
          // So we should clear the ThreadLocal
          if (activeTable != null) {
            activeTable.remove();
          }
        }
        old = null; // avoid memory leak
    }

[glassfishrobot]

anujshahwork said:
I have a simple one line fix and accompanying test in a patch. This has been attached to the forum.

http://glassfish.10926.n7.nabble.com/file/n87597/JAXB-937.patch

[glassfishrobot]

yaroska said:
Fixed in JAXB 2.2.8

[glassfishrobot]

Marked as fixed on Wednesday, July 31st 2013, 6:15:48 am

[glassfishrobot]

schafdog said:
I am seeing a very similar crash, but as far as I can see there is no nested here. Implement this project

http://blog.bdoughan.com/2012/02/xmlanyelement-and-xmladapter.html

(a very simple @XmlAnyElement with a @XmlJavaTypeAdaptor using Java 7u51 jaxb-impl instead of the EclipseLink. The project works fine in Java 6 and Java 7u5. And if I override with jaxb-impl 2.2.4-1.

Or has the API change so the project is no longer valid code?

Secondly, I have checked out the code but I do not see any 2.2.8 tag? I will try with HEAD now to see if this fixes it.

[glassfishrobot]

This issue was imported from java.net JIRA JAXB-937