castor
  1. castor
  2. CASTOR-478

Ordering of attributes with location in the marshalled XML

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 0.9.5
    • Fix Version/s: None
    • Component/s: XML
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: All
    • Bugzilla Id:
      1338
    • Number of attachments :
      1

      Description

      Attributes with location always appears last ones in the marshalled XML
      although they were defined in first place of mapping file.

      Example:

      <mapping>
      <class name="Class">
      <map-to xml="my-class" />
      <field name="firstField" type="string">
      <bind-xml name="first_field" location="foo" node="attribute" />
      </field>
      <field name="secondField" type="string">
      <bind-xml name="second_field" node="element" />
      </field>
      </class>
      </mapping>

      [desired output]
      <my-class>
      <foo first_field="aValue" />
      <second_filed>anotherValue</second_field>
      </my-class>

      [desired output]
      <my-class>
      <second_filed>anotherValue</second_field>
      <foo first_field="aValue" /> <!-- must be the first !!! -->
      </my-class>

      PD: Keith, I known you're working in "virtual fields" and rewriting the code. I
      hope this will fixed in next release.

        Activity

        Hide
        Igor Devor added a comment -

        Thank Ralf, it could be very great if you find a solution.

        Show
        Igor Devor added a comment - Thank Ralf, it could be very great if you find a solution.
        Hide
        David Lopez added a comment -

        I've found the submitted patch. But I'm not sure even if it could be applied to Castor current version.

        Hope it'll be useful for somebody.

        Show
        David Lopez added a comment - I've found the submitted patch. But I'm not sure even if it could be applied to Castor current version. Hope it'll be useful for somebody.
        Hide
        Ralf Joachim added a comment -

        I also expect that the patch can not be applied as is but it seams to be a good starting point where to look at.

        Thank you for the time you spend searching for it.

        Show
        Ralf Joachim added a comment - I also expect that the patch can not be applied as is but it seams to be a good starting point where to look at. Thank you for the time you spend searching for it.
        Hide
        Neutrolio added a comment -

        Is the responsable for this issue dead?

        Show
        Neutrolio added a comment - Is the responsable for this issue dead?
        Hide
        Werner Guttmann added a comment -

        No, not really .. . But 'Unassigned' usually indicates that nobody is working on this issue right now. Having said that, how about helping us, by e.g. providing us with a (unified) patch against SVN trunk and/or a JUnit test case that we could use to replay the problem (and thus think about a possible solution).

        Show
        Werner Guttmann added a comment - No, not really .. . But 'Unassigned' usually indicates that nobody is working on this issue right now. Having said that, how about helping us, by e.g. providing us with a (unified) patch against SVN trunk and/or a JUnit test case that we could use to replay the problem (and thus think about a possible solution).

          People

          • Assignee:
            Unassigned
            Reporter:
            David Lopez *eSpencer*
          • Votes:
            6 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated: