Bug #7967
The CN is not following the xml schema definition when creating dataone exceptions
30%
Description
when updating the schemas in 2013 for V2, the field 'pid' was changed to 'identifier'. d1_common_java did not implement this change, yet GMN has. So we have two supported MN software stacks "in the wild" that require different xml delivered with mn.synchronizationFailed(Session s, SynchronizationFailedException x). Fixing for one breaks the other.
We will need to choose whether or not we support 'pid' as a field or 'identifier'.
The CN might be able to mitigate the impact for the short term by sending different versions of the xml, depending on which MN it is sending the synchronizationFailed message to. (This would be entirely within the synchronization code).
Fixing of this bug requires
1) making a decision on which field name to use.
2) updating the documentation
3) possibly updating the schema
4) developing a custom mn.synchronizationFailed() client call and logic for knowing when to send the variant
Related issues
Associated revisions
refs: #7967. customize the synchronizationFailed message sent in SyncFailedtask.submitSynchronizationFailed() based on MN API version.
refs: #7967. customize the synchronizationFailed message sent in SyncFailedtask.submitSynchronizationFailed() based on MN API version.
History
#1 Updated by Rob Nahf almost 8 years ago
- Related to Story #4188: dataone Exception definition and implementation requires clarification added
#2 Updated by Rob Nahf over 6 years ago
a clean implementation to the differential xml solution requires modifying SynchronizationFailed.serialize method. Unfortunately, that class is not versioned, and lives in d1_common_java, so would be a change that would touch all of our java code that's deployed to the CN.
Since synchronization only uses PIDs for that field, why did we change the field name?
Can we revisit changing the schema back to "pid"?
#3 Updated by Rob Nahf over 6 years ago
an adaptive strategy would be for synchronization to send the error xml using 'pid', and if a service failure on the call is returned, then to send using 'identifier', and learn / remember the Member Node's choice.
This is complicated, but works in theory because only those using a schema will return an exception, and the schema uses 'identifier'. Those not using a schema will likely just see the identifier field as null. right?
#4 Updated by Rob Nahf over 6 years ago
Because BaseException is versionless, and is only responsible for serialization (not deserialization), I completely separated the 'pid' property/setter/getter from the 'identifier' property/setter/getter. This lets the user choose which property to be used, and both can be set independently.
Of course, users will need to be more cautious in what to set if they don't know if the receiver will be validating the schema (error.xml).
ExceptionHandler.deserializeXML will deserialize either property to the identifier field, so it's no longer completely reversible. This is OK.
#5 Updated by Rob Nahf over 6 years ago
in V2.4 (trunk), I customized the synchronizationFailed message being sent based on MN API version. V1 gets 'pid', V2 gets 'identifier'
#6 Updated by Rob Nahf over 6 years ago
- % Done changed from 0 to 30
- Status changed from New to In Progress
