Uploaded image for project: 'MidPoint'
  1. MidPoint
  2. MID-2191

Formalize rules for using unqualified QNames and review the code accordingly

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 5.0
    • Component/s: None
    • Labels:
      None

      Description

      There are places in code where unqualified names cause problems.

      E.g. when set (ri:l).tolerant to false, some values began to disappear. The reason lies very probably in xmlns-related problems, as can be seen from the log:

      Account squeezed attributes:
              {...resource/instance-3}l => 
                DeltaSetTriple:
                  zero:
                    ItemValueWithOrigin:
                      itemValue:
                        middle of nowhere
                      mapping: M({...resource/instance-3}l = PVDeltaSetTriple(zero: [PPV(String:middle of nowhere)]; plus: []; minus: []; ))
                      construction: Construction(unknown)
                  plus:
                  minus:
      (...)
              l => 
                DeltaSetTriple:
                  zero:
                    ItemValueWithOrigin:
                      itemValue:
                        worker
                      mapping: M(l = PVDeltaSetTriple(zero: [PPV(String:worker)]; plus: []; minus: []; ), strong)
                      construction: Construction(Discr(account (default) on ef2bc95b-76e0-48e2-86d6-3d4f02d3e1a2))
                    ItemValueWithOrigin:
                      itemValue:
                        director
                      mapping: M(l = PVDeltaSetTriple(zero: [PPV(String:director)]; plus: []; minus: []; ), strong)
                      construction: Construction(Discr(account (default) on ef2bc95b-76e0-48e2-86d6-3d4f02d3e1a2))
                  plus:
                  minus: 
      (...)
      

      Both entries ri:l and l are present here, which causes problems later in processing.

      2015-01-30 18:27:17,304 [MODEL] [http-8080-1] TRACE (com.evolveum.midpoint.model.impl.lens.projector.ReconciliationProcessor): Attribute reconciliation processing account(ID {.../connector/icf-1/resource-schema-3}uid = [ 217c1c8f-1f75-40fa-a210-ef231e8b48f9 ], type 'default', resource:ef2bc95b-76e0-48e2-86d6-3d4f02d3e1a2(Localhost OpenDJ (no extension schema)))
      2015-01-30 18:27:17,305 [MODEL] [http-8080-1] TRACE (com.evolveum.midpoint.model.impl.lens.projector.ReconciliationProcessor): Reconciliation will DELETE value of attribute LRRAD:{.../resource/instance-3}l {xsd:}string[0,-1],RAM,OUT,IN: worker
      2015-01-30 18:27:17,305 [MODEL] [http-8080-1] TRACE (com.evolveum.midpoint.model.impl.lens.projector.ReconciliationProcessor): Reconciliation will DELETE value of attribute LRRAD:{.../resource/instance-3}l {xsd:}string[0,-1],RAM,OUT,IN: director
      2015-01-30 18:27:17,305 [MODEL] [http-8080-1] TRACE (com.evolveum.midpoint.model.impl.lens.projector.ReconciliationProcessor): Reconciliation will DELETE value of attribute LRRAD:{.../resource/instance-3}l {xsd:}string[0,-1],RAM,OUT,IN: middle of nowhere
      

      (actually don't know why also the 'middle of nowhere' is deleted but it is clear why 'director' and 'worker' are)

      Similar situation was seen when handling association names.

      I suggest to formalize where it is allowed to use unqualified names, and which part of midPoint code is responsible for correcting them (if any).

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              mederly Pavol Mederly
              Reporter:
              mederly Pavol Mederly
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated: