Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2.3
    • Fix Version/s: None
    • Component/s: runtime
    • Labels:
      None

      Description

      We found problem in following scenario:
      1. unmarshall object stored in file user-template.xml
      Note: unmarshall works ok.
      2. marshall java jaxb object (from previous step)
      Problem: marshall is not working properly. AccountConstruction's child tag resourceRef is replaced by wrong tag property:
      ...
      <i:accountConstruction>
      <m:resourceRef oid="c0c010c0-d34d-b33f-f00d-333111111112" type="ResourceType"/>
      <m:type>default</m:type>
      </i:accountConstruction>
      ...

      ...
      <accountConstruction>
      <ns2:property oid="c0c010c0-d34d-b33f-f00d-333111111112" type="ResourceType" xmlns="" xmlns:ns2="http://midpoint.evolveum.com/xml/ns/public/common/common-1.xsd"/>
      <type>default</type>
      </accountConstruction>
      ...

      Attached is a simple maven project that simulates our problem.
      File common-1.xsd contains definitions for all common object in the project.
      File user-template.xml holds sample object definition that smulates the problem.
      Package com.evolveum.midpoint.xml.ns._public.common.common_1 contains all jaxb generated classes.

        Activity

        Hide
        ifarinic added a comment -

        The problem was a missing namespace prefix in attribute type: c:ResourceType.

        Correct xml snippet is:
        <m:resourceRef oid="c0c010c0-d34d-b33f-f00d-333111111112" type="c:ResourceType"/>

        Show
        ifarinic added a comment - The problem was a missing namespace prefix in attribute type: c:ResourceType. Correct xml snippet is: <m:resourceRef oid="c0c010c0-d34d-b33f-f00d-333111111112" type="c:ResourceType"/>
        Hide
        Martin Grebac added a comment -

        So you say it was an error in yout app and this issue shall be closed?

        Show
        Martin Grebac added a comment - So you say it was an error in yout app and this issue shall be closed?
        Hide
        ifarinic added a comment -

        I am just saying that we had problem in the input data, however IMHO marshaller should fail and report problem and not convert data to wrong unrelated tag.
        The other interesting observation is that unmarshaller unmarshalled the xml into java object that "seemed" fine in debugger.

        Show
        ifarinic added a comment - I am just saying that we had problem in the input data, however IMHO marshaller should fail and report problem and not convert data to wrong unrelated tag. The other interesting observation is that unmarshaller unmarshalled the xml into java object that "seemed" fine in debugger.
        Hide
        Martin Grebac added a comment -

        The problem is in the classes themselves. The way they are designed now make the runtime expect ObjectReferenceType first, because there's no choice access generated. Usually choiceContentProperty (to generate getAorB) shall help here but for some reason it is being ignored as well, so need to look why that is happening - maybe the complex type substitution does not allow such a construct.

        Show
        Martin Grebac added a comment - The problem is in the classes themselves. The way they are designed now make the runtime expect ObjectReferenceType first, because there's no choice access generated. Usually choiceContentProperty (to generate getAorB) shall help here but for some reason it is being ignored as well, so need to look why that is happening - maybe the complex type substitution does not allow such a construct.
        Hide
        Martin Grebac added a comment -

        OK, so the choiceContentProperty has been disabled by some mysterious Kohsuke's commit loong time ago, so that I will revert. However, studying the reasons why that does not apply for this case I came across this statement:
        // My reading of the spec is that if a complex type is
        // derived from another complex type by extension,
        // its top level model group is always a sequence
        // that combines the base type content model and
        // the extension defined in the new complex type.
        which is the reason why choiceContentProperty cannot apply here.

        Show
        Martin Grebac added a comment - OK, so the choiceContentProperty has been disabled by some mysterious Kohsuke's commit loong time ago, so that I will revert. However, studying the reasons why that does not apply for this case I came across this statement: // My reading of the spec is that if a complex type is // derived from another complex type by extension, // its top level model group is always a sequence // that combines the base type content model and // the extension defined in the new complex type. which is the reason why choiceContentProperty cannot apply here.

          People

          • Assignee:
            Martin Grebac
            Reporter:
            ifarinic
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: