scalaxb 1.2.0 is released

[eugene yokota]

Hi guys,

scalaxb 1.2.0 is out from Berlin!

Thanks for all the bug reports and code contributions.

-eugene

## non-blocking SOAP

scalaxb 1.2.0 generates non-blocking SOAP code by default. Instead of `Either[X, A]`, the SOAP call returns `Future[A]` and the fault, if any, is thrown as `Future`'s failure semantics.

    // default

    def getQuote(symbol: Option[String]): Future[stockquote.GetQuoteResponse]

    // async in (Compile, scalaxb) := false

    def getQuote(symbol: Option[String]): Either[scalaxb.Fault[Any], stockquote.GetQuoteResponse]

This feature was contributed by [@jlavallee][@jlavallee] and [@hoff2][@hoff2] as [#213][213]/[#259][259].

## SOAP bug fixes

- Escapes reserve words appearing as a parameter in SOAP. [#252][252]/[#256][256] contributed by [@romainreuillon][@romainreuillon]

- Escapes reserve words appearing as an operation name in SOAP. [#241][241] reported by [@rcgoodfellow][@rcgoodfellow]

- Fixes handling of nillable elements appearing in SOAP. [#229][229] reported by [@barnesjd][@barnesjd]

- Fixes string encoding problems while posting SOAP. [#231][231] reported by [@hedefalk][@hedefalk]

- Supports Dispatch 0.11.1.

- Fixes response parsing for literal RPC style. [#260][260] reported by [@romainreuillon][@romainreuillon]

## bug fixes and minor enhancements

- Drops Scala 2.9.0 and removing deprecated warnings.

- Caches `DatatypeFactory` instance to `ThreadLocal`. [#243][243] contributed by [@malaporte][@malaporte]

- Fixes handing of zero-length prefix. [#253][253]/[#255][255] contributed by [@romainreuillon][@romainreuillon]

- Fixes `mixed` attribute not being inherited when extending a complex type. [#228][228] reported by [@choffmeister][@choffmeister]

- Fixes non-terminating parser when `unbounded` is nested. [#230][230] reported by [@FranklinChen][@FranklinChen]

- Fixes handling of `xs:element` with `default` with `minOccurs = 1`. [#245][245] reported by [@alboko][@alboko]

- Fixes handling of very long `xs:enumeration` value. [#247][247] reported by [@jcranky][@jcranky]

- Fixes handling of `xs:element` names with symbols when `--class-prefix` is passed. [#251][251] reported by [@romangarcia][@romangarcia]

- Fixes `xs:group` parser getting inherited twice. [#238][238] reported by [@choeger][@choeger]

  [228]: https://github.com/eed3si9n/scalaxb/issues/228

  [229]: https://github.com/eed3si9n/scalaxb/issues/229

  [230]: https://github.com/eed3si9n/scalaxb/issues/230

  [231]: https://github.com/eed3si9n/scalaxb/issues/231

  [238]: https://github.com/eed3si9n/scalaxb/issues/238

  [241]: https://github.com/eed3si9n/scalaxb/issues/241

  [245]: https://github.com/eed3si9n/scalaxb/issues/245

  [247]: https://github.com/eed3si9n/scalaxb/issues/247

  [251]: https://github.com/eed3si9n/scalaxb/issues/251

  [252]: https://github.com/eed3si9n/scalaxb/issues/252

  [253]: https://github.com/eed3si9n/scalaxb/issues/253

  [213]: https://github.com/eed3si9n/scalaxb/pull/213

  [243]: https://github.com/eed3si9n/scalaxb/pull/243

  [255]: https://github.com/eed3si9n/scalaxb/pull/255

  [256]: https://github.com/eed3si9n/scalaxb/pull/256

  [259]: https://github.com/eed3si9n/scalaxb/pull/259

  [@choffmeister]: https://github.com/choffmeister

  [@barnesjd]: https://github.com/barnesjd

  [@jcranky]: https://github.com/jcranky

  [@rcgoodfellow]: https://github.com/rcgoodfellow

  [@romainreuillon]: https://github.com/romainreuillon

  [@alboko]: https://github.com/alboko

  [@romangarcia]: https://github.com/romangarcia

  [@choeger]: https://github.com/choeger

  [@jlavallee]: https://github.com/jlavallee

  [@hoff2]: https://github.com/hoff2

  [@FranklinChen]: https://github.com/FranklinChen

  [@hedefalk]: https://github.com/hedefalk

  [@malaporte]: https://github.com/malaporte

[Viktor Hedefalk]

Hi,

Awesome.

I'm having trouble compiling the generated code:


package scalaxb

trait HttpClientsAsync {
def httpClient: HttpClient

trait HttpClient {
import dispatch._
def request(in: String, address: java.net.URI, headers:
Map[String, String]): Future[String]
}
}

[error] /Users/viktor/dev/projects/uniply/target/scala-2.10/src_managed/main/sbt-scalaxb/scalaxb/httpclients_async.scala:8:
not found: type Future
[error] def request(in: String, address: java.net.URI, headers:
Map[String, String]): Future[String]


Isn't there simply a missing import for Future?

Thanks,
Viktor

> --
> You received this message because you are subscribed to the Google Groups
> "scalaxb" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scalaxb+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Viktor Hedefalk]

Might be worth noting that:

async in scalaxb in Compile := false

makes you able go upgrade without rewrite of client code. But trying
this I instead get:

[error] /Users/viktor/dev/projects/uniply/target/scala-2.10/src_managed/main/sbt-scalaxb/scalaxb/httpclients_dispatch.scala:7:
object Defaults in package dispatch cannot be accessed in package
dispatch
[error] import dispatch._, Defaults._

Just removing ", Defaults._" from the import works fine.


Should I make a pull request on the templates?

Cheers,
Viktor

[Paulo "JCranky" Siqueira]

Hi,

I might have a regression. Code that was working on 1.1.2 now breaks under 1.2.0 with the following:

java.lang.NoSuchMethodError: br.com.doit.easynfe.nfe.evento.canc.XMLProtocol$DefaultCancTransformsTypeFormat.safeRep(Lscala/Function0;)Lscala/util/parsing/combinator/Parsers$Parser;
    at br.com.doit.easynfe.nfe.evento.canc.XMLProtocol$DefaultCancTransformsTypeFormat$class.parser(xmlprotocol.scala:743)
    at br.com.doit.easynfe.nfe.evento.canc.XMLProtocol$$anon$13.parser(xmlprotocol.scala:51)
    at scalaxb.ElemNameParser$class.reads(scalaxb.scala:659)
    at br.com.doit.easynfe.nfe.evento.canc.XMLProtocol$$anon$13.reads(xmlprotocol.scala:51)
    at scalaxb.package$.fromXML(scalaxb.scala:13)

The misbehaving xsds seems be this group (I have more in there, but the package br.com.doit.easynfe.nfe.evento.canc is given to those):

http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=rkpU2AGa/TA=

(yes, crazy URLs... =[ )

[]s,

--

[]s,

Paulo "JCranky" Siqueira
youtube | site | lojinha

[eugene yokota]

Hi Viktor,

What's your setting on dispathVersion in (Compile, scalaxb)?

-eugene

[eugene yokota]

I didn't see the issue because I'm using Dispatch in my integration test.

Are you using something that's not Dispatch? I'm guessing Future is coming from "import dispatch._", which is bad.

Could you open a github issue for this, please?

-eugene

On Wed, Jun 25, 2014 at 9:06 AM, Viktor Hedefalk <hede...@gmail.com> wrote:

[eugene yokota]

Is this a runtime error?

If so could you open a Github issue with a response XML so I can reproduce it?

-eugene

[Viktor Hedefalk]

I have no explicit setting.

[Viktor Hedefalk]

I think I have a bit of unnecessary code here that was workarounds
that probably aren't needed. This is my code:

val service = new ServiceSoap11Bindings with scalaxb.Soap11Clients
with HttpClients {
/** Override to choose endpoint */
override def baseAddress = Config.CrmSettings.baseAddress match {
case Some(address) => new java.net.URI(address)
case None => {
warn("No endpoint settings to CRM found in Config. Using
default from WSDL."); super.baseAddress
}
}

/** Override http binding to use basic http auth creds */
override lazy val httpClient = new HttpClient {
override def request(in: String, address: java.net.URI, headers:
Map[String, String]): String = {
import dispatch._
val http = new Http
val req = (Config.CrmSettings.user, Config.CrmSettings.password) match {
case (Some(user), Some(pwd)) =>
url(address.toString).setBodyEncoding("UTF-8") << (in) <:< headers
as(user, pwd)
case _ => url(address.toString).setBodyEncoding("UTF-8") <<
(in) <:< headers
}
val s = Http(req > as.String)
s()
}
}

}.service


However, its the library code generated by scalaxb that doesn't
compile. Oooh noes. I'ts probably because I have dispatch as a dep on
my project.

Yep:

"net.databinder.dispatch" %% "dispatch-core" % "0.9.5",

Crap, either I have to upgrade that too or go OSGI i guess.

Hm, probably will upgrade.

Thanks,
Viktor

[Viktor Hedefalk]

Ah, ok. I'm typing too much and reading/thinging too little.

A question: this dispatchVersion setting in scalaxb, how is that used?
Is the dependency to dispatch of that version added to the build for
the compile phase or is it something of more magic?

Say I use dispatch already for something else, should I set the
version there to the version I already use (0.9.5 apparently) and it
just might work?

Thanks,
Viktor

[eugene yokota]

On Wed, Jun 25, 2014 at 9:53 PM, Viktor Hedefalk <hede...@gmail.com> wrote:

Ah, ok. I'm typing too much and reading/thinging too little.

A question: this dispatchVersion setting in scalaxb, how is that used?

dispatchVersion in (Compile, scalaxb) := "0.9.5"

Is the dependency to dispatch of that version added to the build for
the compile phase or is it something of more magic?

No, this is used just to advise code gen. It doesn't add dependency to Dispatch, since you might not want to use it.

Say I use dispatch already for something else, should I set the
version there to the version I already use (0.9.5 apparently) and it
just might work?

That's the idea. 

[Viktor Hedefalk]

Ah, okej. Now I get it. Awesome.

So now with:

async in scalaxb in Compile := false

dispatchVersion in (Compile, scalaxb) := "0.9.5"

I have it compiling with scalaxb 1.2.0 and no code changes. Thanks!


Should I still open a bug that the contract on async client uses
dispatch's Future? I guess that still holds, right?

/Viktor

[eugene yokota]

Yup. Thanks for opening #269.

-eugene

[Paulo "JCranky" Siqueira]

Hi Eugene,

Yes, it is a runtime error. I'm having trouble reproducing it, though.

This is a web, maven project, and I'm using the scalaxb-maven-plugin. If I start the scala console with mvn scala:console and then try scalaxb.fromXML from there, it works.

Now, when running from within Tomcat, it breaks - the very same code that worked with 1.1.2. The problem seems to happen with other XSDs as well, not only that one.

Is there any dependency differences I should mind? Perhaps some transitive stuff is not being pulled, that was pulled before?

[]s,

[Martin Ellis]

Hi Paulo,

I'm not sure what's going on here, so just clutching at straws.

What Scala version are you using?
If 2.11, is it possible that scala:console is using the
scala-library-all [1], but your project only has scala-library [2] on
the classpath?

I'd have expected a very different error if so, but that's the only
thing I can think of.

Martin

[1] http://uk.maven.org/maven2/org/scala-lang/scala-library-all/
[2] http://uk.maven.org/maven2/org/scala-lang/scala-library/


On 26 June 2014 13:56, Paulo "JCranky" Siqueira

[Paulo "JCranky" Siqueira]

Hi Martin,

I considered that as well and double checked my dependencies. I'm still on scala 2.10.4 =(

[]s,

[eugene yokota]

You're getting:

java.lang.NoSuchMethodError: br.com.doit.easynfe.nfe.evento.canc.XMLProtocol$DefaultCancTransformsTypeFormat.safeRep(Lscala/Function0;)Lscala/util/parsing/combinator/Parsers$Parser;

so I suspect you might have multiple scalaxb.class along your classpath, one from the generated code, and another from scalaxb itself.

-eugene

[Paulo "JCranky" Siqueira]

Eugene,

That is possible as well. I'm not sure where that would happen from. I have a separated project for scalaxb to do its magic, and another project (the web project) that depends on the first one.

I just confirmed that the web project does not adds scalaxb directly as a dependency. Also, I didn't find scalaxb anywhere as a transitive dependency as well.

Perhaps the way I use the maven plugin is now bad? I basically have:

    <plugin>
        <groupId>org.scalaxb</groupId>
        <artifactId>scalaxb-maven-plugin</artifactId>
        <version>1.2.0</version>
        <executions>

            <execution ... >
            <execution ... >

        </executions>

    </plugin>

Meaning that I have on <execution> for each bunch of xsds whose resulting code I wish to place in different package / folders. Could that be a problem? It worked until 1.1.2.

[]s,

[Martin Ellis]

Hi Paulo,

Using two executions of scalaxb will generate two copies of the
scalaxb runtime unless one of the executions sets the generateRuntime
option to false.

"generateRuntime: Generate the scalaxb classes required to use
the generated bindings. This option is useful for preventing duplicate
copies of the scalaxb runtime being present on the classpath when
more than one jar contains scalaxb bindings. To prevent the scalaxb
runtime sources being generated, this option should be set to false."
-- http://martiell.github.io/scalaxb/maven/generate-mojo.html#generateRuntime

However, if the two versions of the scalaxb runtime on the classpath
are identical, I'm not sure why it'd be a problem to have both.
Also, I'm not sure how you'd even compile it if you had two copies of
the scalaxb runtime in your generated-sources.

Martin



On 30 June 2014 14:08, Paulo "JCranky" Siqueira

[Paulo "JCranky" Siqueira]

I tested adding the generateRuntime to false, just in case, but nothing changed. I don't think this should be a problem here because everything is going in in the same jar, so the "extras" are just overwriting the previously generated ones.

Now, I think your question got me to the problem: I actually have another project using scalaxb, that is also on the classpath - but I forgot to update the scalaxb version there! This is probably the real problem. I still can't confirm that because updating scalaxb there caused other problems which I'll isolate and post in a new thread.

thank you!

[]s,