Grouper
  1. Grouper
  2. GRP-139

XmlExporter fails if a subject cannot be resolved and gives truncated output

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.3.0
    • Fix Version/s: 1.3.1
    • Component/s: API
    • Labels:
      None

      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.

        Activity

        Hide
        Gary Brown added a comment -
        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
        Show
        Gary Brown added a comment - 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
        Hide
        Gary Brown added a comment -
        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.
        Show
        Gary Brown added a comment - 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.

          People

          • Assignee:
            Gary Brown
            Reporter:
            Gary Brown
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: