Project

General

Profile

Bug #7967

The CN is not following the xml schema definition when creating dataone exceptions

Added by Rob Nahf almost 5 years ago. Updated over 3 years ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Architecture Design
Target version:
Start date:
2017-01-14
Due date:
% Done:

30%

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

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

Related to Infrastructure - Story #4188: dataone Exception definition and implementation requires clarification In Progress 2013-11-27

Associated revisions

Revision 19255
Added by Rob Nahf over 3 years ago

refs: #7967. customize the synchronizationFailed message sent in SyncFailedtask.submitSynchronizationFailed() based on MN API version.

Revision 19255
Added by Rob Nahf over 3 years ago

refs: #7967. customize the synchronizationFailed message sent in SyncFailedtask.submitSynchronizationFailed() based on MN API version.

History

#1 Updated by Rob Nahf almost 5 years ago

  • Related to Story #4188: dataone Exception definition and implementation requires clarification added

#2 Updated by Rob Nahf over 3 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 3 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 3 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 3 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 3 years ago

  • % Done changed from 0 to 30
  • Status changed from New to In Progress

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)