https://redmine.dataone.org/https://redmine.dataone.org/favicon.ico2017-01-14T01:13:02ZDataONE TasksInfrastructure - Bug #7967: The CN is not following the xml schema definition when creating dataone exceptionshttps://redmine.dataone.org/issues/7967?journal_id=283622017-01-14T01:13:02ZRob Nahfrnahf@epscor.unm.edu
<ul><li><strong>Related to</strong> <i><a class="issue tracker-4 status-2 priority-4 priority-default parent" href="/issues/4188">Story #4188</a>: dataone Exception definition and implementation requires clarification</i> added</li></ul> Infrastructure - Bug #7967: The CN is not following the xml schema definition when creating dataone exceptionshttps://redmine.dataone.org/issues/7967?journal_id=304002018-05-21T18:29:18ZRob Nahfrnahf@epscor.unm.edu
<ul></ul><p>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.</p>
<p>Since synchronization only uses PIDs for that field, why did we change the field name?</p>
<p>Can we revisit changing the schema back to "pid"? </p>
Infrastructure - Bug #7967: The CN is not following the xml schema definition when creating dataone exceptionshttps://redmine.dataone.org/issues/7967?journal_id=304012018-05-21T19:02:42ZRob Nahfrnahf@epscor.unm.edu
<ul></ul><p>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.</p>
<p>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?</p>
Infrastructure - Bug #7967: The CN is not following the xml schema definition when creating dataone exceptionshttps://redmine.dataone.org/issues/7967?journal_id=304022018-05-22T04:45:02ZRob Nahfrnahf@epscor.unm.edu
<ul></ul><p>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.</p>
<p>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).</p>
<p>ExceptionHandler.deserializeXML will deserialize either property to the identifier field, so it's no longer completely reversible. This is OK.</p>
Infrastructure - Bug #7967: The CN is not following the xml schema definition when creating dataone exceptionshttps://redmine.dataone.org/issues/7967?journal_id=304042018-05-23T18:13:44ZRob Nahfrnahf@epscor.unm.edu
<ul></ul><p>in V2.4 (trunk), I customized the synchronizationFailed message being sent based on MN API version. V1 gets 'pid', V2 gets 'identifier'</p>
Infrastructure - Bug #7967: The CN is not following the xml schema definition when creating dataone exceptionshttps://redmine.dataone.org/issues/7967?journal_id=304052018-05-23T18:13:59ZRob Nahfrnahf@epscor.unm.edu
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>30</i></li><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul>