[GRP-139] XmlExporter fails if a subject cannot be resolved and gives truncated output Created: 04/Jul/08  Updated: 05/Aug/08  Resolved: 05/Aug/08

Status: Resolved
Project: Grouper
Component/s: API
Affects Version/s: 1.3.0
Fix Version/s: 1.3.1

Type: Bug Priority: Minor
Reporter: Gary Brown (Inactive) Assignee: Gary Brown (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

-Loris Bennett via grouper-users-
OK, I have found what was causing the trouble. The following was written
to grouper_error.log:

2008-07-04 10:47:05,274: unable to export to xml: No results:
searchSubject searchValue: 332279

Something, probably my fiddling around with sources.xml, had invalidated
some IDs used by search subject. I found several groups, the members of
which could not be displayed, and deleted these. After that the export
worked.

However, this error situation causes the write-operation to fail at a
seemingly random point:

...
<internalAttributes>
<internalAttribute
name='parentStem'>TestFolder:subfolder</internalAttribute>
<internalAttribute name='createSubject'>
<subject id='GrouperSystem' type='application'
source='g:isa'/>
</internalAttribute>
<internalAttribute
name='createTime'>1212134050347</internalAttribute> <!-- Fri May 30
09:54:10 CEST 2008 -->
<internalAttribute name='modifySubject'>
<subject id='GrouperSystem' type='application'
source='g:isa'/>
</internalAttri
(EOF)

which is obviously not desirable. Perhaps somebody can look into this
scenario.

 Comments   
Comment by Gary Brown (Inactive) [ 04/Jul/08 ]

Looks like we could flush the output stream...

We could also look at not failing. We have the subject id and source available so we could write something based on that if there is a lookup error, and simply log an error. We could also have flags in import.properties and export.properties which define behaviour if a subject cannot be looked up i.e. fail or log and continue

Comment by Gary Brown (Inactive) [ 05/Aug/08 ]

Added new options:
import.data.fail-on-unresolvable-subject=false
export.data.fail-on-unresolvable-subject=false

Internally use LazySubject so that Member.getSubject() only called when necessary. This actually prevents errors for exporting unless custom attributes are exported also. For export, when writing Subject xml a comment is written if there is an error we now ignore and the error is logged - the first time a subject cannot be resolved..

For import `ignored` errors are logged.

Hopefully there will be a performance improvement as Subjects are not always resolved. Further improvement will come from querying Member information at the same time as Memberships.

Generated at Thu Apr 25 16:02:37 UTC 2024 using Jira 9.4.18#940018-sha1:32a59db0b032756f9bbd6a22c656d21edb3fb41f.