Project

General

Profile

Task #7836

Story #7832: migrate from JibX to JAXB for XML binding / codegen

refactor JiBXException out of TypeMarshaller methods

Added by Rob Nahf almost 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
d1_common_java
Target version:
-
Start date:
2016-06-28
Due date:
% Done:

100%

Milestone:
None
Product Version:
*
Story Points:
Sprint:

Description

The JiBXException is an implementation-specific exception that should be generalized, especially now that we are replacing JiBX with JAXB.
Choose a DataONE or JAVA specific exception that can serve as a replacement.

Associated revisions

Revision 18196
Added by Rob Nahf almost 6 years ago

refs #7836. Refactored JiBXException out of d1_common_java method signatures, replacing with a new org.dataone.exceptions.MarshallingException. Bumped minor version to 2.3.0-SNAPSHOT.

Revision 18196
Added by Rob Nahf almost 6 years ago

refs #7836. Refactored JiBXException out of d1_common_java method signatures, replacing with a new org.dataone.exceptions.MarshallingException. Bumped minor version to 2.3.0-SNAPSHOT.

Revision 18197
Added by Rob Nahf almost 6 years ago

refs #7836. Replacing use of JiBXException with new MarshallingException. Bumped minor versions to 2.3.0-SNAPSHOT.

Revision 18197
Added by Rob Nahf almost 6 years ago

refs #7836. Replacing use of JiBXException with new MarshallingException. Bumped minor versions to 2.3.0-SNAPSHOT.

Revision 18198
Added by Rob Nahf almost 6 years ago

refs #7836. Replacing use of JiBXException with new MarshallingException. Bumped minor versions to 2.3.0-SNAPSHOT.

Revision 18198
Added by Rob Nahf almost 6 years ago

refs #7836. Replacing use of JiBXException with new MarshallingException. Bumped minor versions to 2.3.0-SNAPSHOT.

Revision 18199
Added by Rob Nahf almost 6 years ago

refs #7836. Replacing use of JiBXException with new MarshallingException. Bumped minor versions to 2.3.0-SNAPSHOT.

Revision 18199
Added by Rob Nahf almost 6 years ago

refs #7836. Replacing use of JiBXException with new MarshallingException. Bumped minor versions to 2.3.0-SNAPSHOT.

Revision 18200
Added by Rob Nahf almost 6 years ago

refs #7836. Replacing use of JiBXException with new MarshallingException. Bumped minor versions to 2.3.0-SNAPSHOT.

Revision 18200
Added by Rob Nahf almost 6 years ago

refs #7836. Replacing use of JiBXException with new MarshallingException. Bumped minor versions to 2.3.0-SNAPSHOT.

Revision 18202
Added by Rob Nahf almost 6 years ago

refs #7836. Replacing use of JiBXException with new MarshallingException. Bumped minor versions to 2.3.0-SNAPSHOT.

History

#1 Updated by Rob Nahf almost 6 years ago

  • Category set to d1_common_java
  • Status changed from New to Closed
  • Assignee set to Rob Nahf
  • % Done changed from 0 to 100
  • translation missing: en.field_remaining_hours set to 0.0

There are three main options for how to do this:
1. use SerializationException
2. use javax.xml.bind.JAXBException and subclasses (MarshalException / ValidationException / UnmarshalException / PropertyException)
3. define our own exception

  1. SerializationException is a RuntimeException, so changing to it would be change in behavior as well as name - throwing an unlikely - handled runtime exception.
  2. JAXB (and along with it, JAXBException) is Java standard so users would get the benefit of subclasses if libraries decide to throw them. JAXB also un/marshals JSON, so it's placement inside an "xml" package is somewhat misplaced, but likely to be durable. DataONE could use the general JAXBException or its subclasses. "JAXBException" is not very transparent, but using the more transparent MarshalException / UnmarshalException doesn't handle all exceptions thrown by JAXB = marshal methods throw MarshalException as well as JAXBException. It is difficult to imagine differential actions taken by users, which argues against taking advantage of the subclasses.

  3. Defining our own exception(s) is probably the most durable and least confusing for DataONE users, and would keep the method signatures simple. Implementation-specific detail would be accessible (although not easily actionable by setting the cause when thrown (for example: throw new MarshallingException("oops",theJAXBException).

All things considered, and after discussion, option 3 is chosen.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)