New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Having typeAttribute true (or serializing derived type as abstract base type) does not serialize attributes #159

Closed
ghost opened this Issue May 26, 2012 · 10 comments

Comments

Projects
None yet
1 participant
@ghost

ghost commented May 26, 2012

Given a base complexType named "ProblematicType" with no attributes and an extension, "SubProblematicType," with attributes,

toXML[ProblematicType](SubProblematicType(...), "Problematic", defaultScope)

does not serialize the attributes, using scalaxb 0.7.1.

I've created a gist with a reproducing test here.

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n May 27, 2012

Owner

I'll look into this today.

Owner

eed3si9n commented May 27, 2012

I'll look into this today.

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n May 27, 2012

Owner

There's a piece of code in scalaxb.scala:

      if (typeAttribute && typeName.isDefined &&
          scope.getPrefix(Helper.XSI_URL) != null) {
        val attrs = writesAttribute(obj, scope)
        val mod = attrs remove (Helper.XSI_URL, scope, "type")
        "scala.xml.Attribute"(scope.getPrefix(Helper.XSI_URL), "type",
          Helper.prefixedName(targetNamespace, typeName.get, scope), mod)
      }

and (I think) it's hitting a Scala bug that I just submitted as SI-5843.
I should be able to work around this by reimplementing remove correctly.

Owner

eed3si9n commented May 27, 2012

There's a piece of code in scalaxb.scala:

      if (typeAttribute && typeName.isDefined &&
          scope.getPrefix(Helper.XSI_URL) != null) {
        val attrs = writesAttribute(obj, scope)
        val mod = attrs remove (Helper.XSI_URL, scope, "type")
        "scala.xml.Attribute"(scope.getPrefix(Helper.XSI_URL), "type",
          Helper.prefixedName(targetNamespace, typeName.get, scope), mod)
      }

and (I think) it's hitting a Scala bug that I just submitted as SI-5843.
I should be able to work around this by reimplementing remove correctly.

@eed3si9n eed3si9n closed this in 7f40a83 May 28, 2012

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n May 28, 2012

Owner

0.7.2-SNAPSHOT is published to https://oss.sonatype.org/content/repositories/public/. In the past, I didn't have sbt 0.10 plugins available for snapshots, but this one does. You can also grab https://github.com/eed3si9n/scalaxb/blob/7f40a83d08bb848f7fd08e756ca72dfbfb660c55/cli/src/main/resources/scalaxb.scala.template for a quite fix.

Owner

eed3si9n commented May 28, 2012

0.7.2-SNAPSHOT is published to https://oss.sonatype.org/content/repositories/public/. In the past, I didn't have sbt 0.10 plugins available for snapshots, but this one does. You can also grab https://github.com/eed3si9n/scalaxb/blob/7f40a83d08bb848f7fd08e756ca72dfbfb660c55/cli/src/main/resources/scalaxb.scala.template for a quite fix.

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n May 29, 2012

Owner

Since scalaxb adds xsi:type="SubProblematicType", your test case needed to be changed as follows:

      ((xml \ "Thing" \ "@type").text must be_==("foo")) and
      (xml must \("Thing", "id"->"bar", "name"->"My Wonderful Thing", "href"->"http://www.example.com/fdhsuihfds"))
Owner

eed3si9n commented May 29, 2012

Since scalaxb adds xsi:type="SubProblematicType", your test case needed to be changed as follows:

      ((xml \ "Thing" \ "@type").text must be_==("foo")) and
      (xml must \("Thing", "id"->"bar", "name"->"My Wonderful Thing", "href"->"http://www.example.com/fdhsuihfds"))
@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 29, 2012

Thanks, Eugene! One note: sbt-scalaxb_2.9.1_0.11.2 (the plugin matching our sbt version and with binary compatibility with Scala 2.9.2) does not appear to have a 0.7.2-SNAPSHOT version, although I do see the 0.7.2-SNAPSHOT under scalaxb_2.9.1. I'm guessing you need to publish the plugin too?

Thanks again!

ghost commented May 29, 2012

Thanks, Eugene! One note: sbt-scalaxb_2.9.1_0.11.2 (the plugin matching our sbt version and with binary compatibility with Scala 2.9.2) does not appear to have a 0.7.2-SNAPSHOT version, although I do see the 0.7.2-SNAPSHOT under scalaxb_2.9.1. I'm guessing you need to publish the plugin too?

Thanks again!

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n May 29, 2012

Owner

I had published for sbt 0.11.3, but I just back published to sbt 0.11.2 too.

Owner

eed3si9n commented May 29, 2012

I had published for sbt 0.11.3, but I just back published to sbt 0.11.2 too.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 30, 2012

Thanks!

Heads up: 0.7.2-SNAPSHOT fixes the issue iff generateRuntime == true. Setting generateRuntime := false causes the bug to reappear.

ghost commented May 30, 2012

Thanks!

Heads up: 0.7.2-SNAPSHOT fixes the issue iff generateRuntime == true. Setting generateRuntime := false causes the bug to reappear.

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n May 30, 2012

Owner

That makes sense since the bug was in scalaxb.scala. When you set generateRuntime to false, where are you getting the runtime from?

Owner

eed3si9n commented May 30, 2012

That makes sense since the bug was in scalaxb.scala. When you set generateRuntime to false, where are you getting the runtime from?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 30, 2012

Yes, I chased it down, and I was mistaken. We were picking up 0.7.0 (!) runtime from another dependency. Fixed now. 0.7.2-SNAPSHOT looks good consistently. Thanks again!

ghost commented May 30, 2012

Yes, I chased it down, and I was mistaken. We were picking up 0.7.0 (!) runtime from another dependency. Fixed now. 0.7.2-SNAPSHOT looks good consistently. Thanks again!

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n May 30, 2012

Owner

I'm glad it worked out!

Owner

eed3si9n commented May 30, 2012

I'm glad it worked out!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment