Issue Details (XML | Word | Printable)

Key: JAXB-476
Type: Task Task
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: jaxb-issues
Reporter: robertotyley
Votes: 1
Watchers: 1

If you were logged in you would be able to see more operations.

PATCH : Exceptions thrown by unmarshal callback methods are currently ignored

Created: 27/Jan/08 01:28 PM   Updated: 26/Sep/12 10:15 AM   Resolved: 29/Mar/09 03:24 AM
Component/s: runtime
Affects Version/s: 2.1.6
Fix Version/s: 2.1.10

Time Tracking:
Not Specified

File Attachments: 1. Text File EnsureExceptionsThrownByUnmarshalCallbackMethodsTerminateTheUnmarshalProcess.txt.patch (1.0 kB) 27/Jan/08 01:29 PM - robertotyley


Operating System: All
Platform: All

Issuezilla Id: 476
Participants: Iaroslav Savytskyi, jaxb-issues, Pavel Bucek, realsonic3 and robertotyley

 Description  « Hide

The JAXB spec says, regarding unmarshal event callbacks (section 4.4.1) : "An
event callback method throwing an exception terminates the current unmarshal

However, currently exceptions thrown by the [before|after]Unmarshal() methods
are ignored because JaxBeanInfo.invokeUnmarshallCallback() reports them using
UnmarshallingContext.handleError(Exception). This ultimately calls the
handleEvent() method with a severity of 'ERROR' (not FATAL_ERROR) and
'canRecover' set to true - this is silently swallowed by the default
ValidationEventHandler, rather than terminating the unmarshal process. This goes
against the spec, and I guess would go against the behaviour the developer would
expect (at least in my case)!

A proposed patch is attached, which simply changes the
JaxBeanInfo.invokeUnmarshallCallback() method to report exceptions with
'canRecover' set to false, which will ensure that an exception is thrown and the
unmarshal process terminated, no matter what.

The following test case re-creates this bug:

public class UnmarshalCallbackMethodsTest {

public static void main(String[] args) throws JAXBException { JAXBContext context = JAXBContext.newInstance(Cabbage.class); String xml = "<cabbage type='red' />"; Cabbage cabbage = (Cabbage) context.createUnmarshaller().unmarshal(new StringReader(xml)); System.out.println("Unmarshalled "+cabbage.type+" cabbage without incident"); }

class Cabbage {

public String type;

void beforeUnmarshal(Unmarshaller unmarshaller, Object parent) { System.out.println("beforeUnmarshal called, about to throw an exception..."); throw new RuntimeException("This exception is ignored..."); }

void afterUnmarshal(Unmarshaller unmarshaller, Object parent) { System.out.println("afterUnmarshal called, about to throw an exception..."); throw new RuntimeException("This exception is also ignored..."); }

The output generated by the test case is:

beforeUnmarshal called, about to throw an exception...
afterUnmarshal called, about to throw an exception...
Unmarshalled red cabbage without incident

Credit to Philippa Tyley for her help in defining this bug!

robertotyley added a comment - 27/Jan/08 01:29 PM

Created an attachment (id=235)
Proposed patch to ensure exceptions in callbacks are not ignored

robertotyley added a comment - 09/Mar/08 06:57 AM

I've completed a Sun Contributor Agreement (SCA) and submitted it to as of 12th January 2008. Any positive/negative feedback on the
patch (whether it's misguided or a just a bit pointless) is welcome!

Pavel Bucek added a comment - 03/Dec/08 06:53 AM


thanks for contributing. Committed to 2.1.10.

robertotyley added a comment - 29/Mar/09 03:24 AM

The "Notable Changes between 2.1.9 to 2.1.10" report
( is based off the
'Target milestone' property, which was unset for this bug so it didn't show up
in the list!

realsonic3 added a comment - 26/Sep/12 05:15 AM

Hello. Regarding to the previous comment (robertotyley added a comment - 29/Mar/09 03:24 AM)... is this issue is really solved?

Iaroslav Savytskyi added a comment - 26/Sep/12 10:15 AM

I see patch changes in the code.