headexplodes / http-stub-server-scala Goto Github PK

I had a body that contained a json array.

It translates to some form of Buffer which does not respond like a normal javascript array.

If the response.body in the javascript world was simply a string it could be processed with JSON.parse.

As it is I am just re-writing the body from scratch using the script block

https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/982501

Specifically I am having this trouble on OSX using what I believe is the latest version of the jdk.

Theoretically I am supposed to be able to provide my own implementation, however I have been unable to locate doco on the bindings and doubt many users of the stub-server would care to work it out.

Some online sources recommend skipping the ScriptingEngine abstraction and just using Rhino directly.

I think that's probably the way to go for http-stub-server

If two standalone stub servers are run simultaneously on different ports, the last one to shut down throws an IllegalStateException "Monitor is not running"

Given I'm using the stub server for automated tests it would be nice if I could start it up without the file monitor running at all

(hoping to fix this myself, just raising it here to remind me to make a pull request)

Given the stub data:

{"exchange":{"request":{"method":"POST","path":"/test","body":"<root>xml</root>"},"response":{"status":200,"headers":[{"name":"Content-Type","value":"text/xml"}],"body":"<xml>works</xml>"}}}

curl -H "Content-Type: text/xml"  -d "<root>xml</root>" -X POST http://localhost:8080/test

gets a result. log extract:

2013-10-10 11:42:29,688 TRACE [pool-5-thread-1] service.StubService (StubService.scala:29) - Got request: {
  "method" : "POST",
  "path" : "/test",
  "headers" : [ {
    "name" : "Accept",
    "value" : "*/*"
  }, {
    "name" : "Content-Length",
    "value" : "16"
  }, {
    "name" : "Content-Type",
    "value" : "text/xml"
  }, {
    "name" : "Host",
    "value" : "localhost:8080"
  }, {
    "name" : "User-Agent",
    "value" : "curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8y zlib/1.2.5"
  } ],
  "body" : "<root>xml</root>"
}
2013-10-10 11:42:29,688 INFO  [pool-5-thread-1] service.StubService$$anonfun$findMatch$1 (StubService.scala:36) - Matched: /test

however:

curl -H "Content-Type: application/xml"  -d "<root>xml</root>" -X POST http://localhost:8080/test

Does not get a match. Extract:

2013-10-10 11:42:25,578 TRACE [pool-5-thread-1] service.StubService (StubService.scala:29) - Got request: {
  "method" : "POST",
  "path" : "/test",
  "headers" : [ {
    "name" : "Accept",
    "value" : "*/*"
  }, {
    "name" : "Content-Length",
    "value" : "16"
  }, {
    "name" : "Content-Type",
    "value" : "application/xml"
  }, {
    "name" : "Host",
    "value" : "localhost:8080"
  }, {
    "name" : "User-Agent",
    "value" : "curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8y zlib/1.2.5"
  } ],
  "body" : "<root>xml</root>"
}
2013-10-10 11:42:25,592 INFO  [pool-5-thread-1] service.StubService (StubService.scala:51) - Didn't match: /test

I vaguely suspect it's related to content encoding, but haven't found exactly what's the mismatch

We are using this server in production and now we have to update the scala version to 2.11 to migrate other new projects. However, the current release is only for 2.10 which is using a lot of 2.10 dependencies. Even we force to use stubby-standalone_2.10 and exclude all the conflict dependencies such as unfiltered and unfinagled. The server it self is built by scala-lang 2.10, which is quite different with 2.11 after compiling. So we are begging to publish a 2.11 release ASAP. Thank you very much.