vert-x / mod-lang-scala Goto Github PK

The current is quite error prone as shown in the user forum. Scala might need to track registrations and pass a reference to the unregister function so that it can do its work (like what Clojure or JRuby do), but we should investigate other solutions.

... on HttpClient and HttpServer by exposing the getter/setter for MaxWebSocketFrameSize

eclipse-vertx/vert.x@8a00f2f

Thanks!

This file should provide information to administrators of the mod-lang-scala repository on how to handle Git pull requests, how do to releases...etc.

pleeeeeeeeeaaaaaaaaaaaaaaasssssssssseeeeeeeeeeee! :)

In the tests you need end up using the Java API for vertx.eventBus().send() for example.

I rewrote TestVerticle in Scala, but that doesn't help, because of the @RunWith(JavaClassRunner.class) which yields an error if the class is not extending the o.v.testtools.TestVerticle.

So please, if possible, somehow help me use all the lang-scala features in the tests, too ;)

Reach parity with Vert.x Java testsuite in terms of API testing. This should be used to detect holes in the Scala API.

@pidster Volunteered to provide a list of APIs missing and @normanmaurer was gonna verify what's missing in the Scala API too on an earlier meeting we had on IRC.

When testing verticle extends with org.vertx.scala.platform.Verticle, it would throw an exception.

java.lang.ClassCastException: verticles.SockJSVerticle cannot be cast to org.vertx.java.platform.Verticle

Here is my deploy code:

container.deployVerticle(
  classOf[SockJSVerticle].getName,
  (ar: AsyncResult[String]) => {

  })

Here is my verticle code

import org.vertx.scala.platform.Verticle

class SockJSVerticle extends Verticle {

   override def start(future: Future[Void]):Unit = {
    start()
   }
} 

Finally got some small time to test the Scala plugin

In the small time I had to play with it I noticed that from the command line the "gradle build" will fail. After doing a "gradle eclipse", setting the project in Eclipse and after converting the project to Gradle nature, then I was able to have it working and playing with it.

The gradle version used was 1.4

Implement org.vertx.java.core.buffer.Buffer in scala, so we can write more idiomatic code.
We can append to a buffer like this:

val buffer: Buffer = ...
buffer << "Hello World!"

Probably a good implementation would be using implicit conversion from Buffer to a RichBuffer.

Current master of vert.x does ship a DNSClient API. We should also provide it here.

It would be great if you'd use a formatter for the Scala code. There are some files where the white spaces look somehow chaotic.

For example: https://github.com/vert-x/mod-lang-scala/blob/master/src/test/scala/org/vertx/scala/tests/FileSystemTest.scala

or https://github.com/vert-x/mod-lang-scala/blob/master/src/main/scala/org/vertx/scala/core/file/FileSystem.scala

Hello,

first, I appreciate what vert-x / mod-lang-scala team is doing. It is great!

Now, when I try to deploy my Scala module i get strange error (on linux, centos 6.4)

environment variables are set: VERTX_HOME and VERTX_MODS

--> my langs.properties:
scala=io.vertxlang-scala0.2.0:org.vertx.scala.platform.impl.ScalaVerticleFactory
.scala=scala

--> my mod.json:
{
// Scala verticle
"main":"scala:demo.Sender",
}

---> Error:

[root@OSOS-platform2 usr]# vertx runMod demoSender0.1 -ha
Starting clustering...
No cluster-host specified so using address 192.168.1.104
A quorum has been obtained. Any deployments waiting on a quorum will now be deployed
Downloading io.vertxlang-scala0.2.0. Please wait...
Downloading 100%
Module io.vertxlang-scala0.2.0 contains an empty mod.json file // it hangs here forever !

What I'm doing wrong ?

Best Regards,
Kresimir

eclipse-vertx/vert.x@ea8b3d0#diff-584e0ff4c0448578612a911d9202355eR241

Has to be done as PR to the vertx.github.io repository, but should be done pretty soon.

Wouldn't it make sense to use scala.util.Try?
Then a user could pattern match over Success(result) and Failure(exception).

Master now contains Datagram support. Would be nice to also provide it here.

eclipse-vertx/vert.x@acfda05

FWIW, instead of having a matcher over the different types for each send(), publish(), reply() methods, it would be much nicer to have type classes. I'm not sure HOW to do it, but I'm sure that it can and should be done with advanced Scala typing-fu.

Related to that: The send method restricts the reply handler to the same type as the sent message. This changed in Vert.x 2.0 and if someone comes up with a solution for the type classes, it should be easy to do without introducing even more of these pattern matching over types.

Post 1.0, Slick integration for persistence in relational DBs would be cool - maybe find some inspiration in https://github.com/vert-x/mod-mongo-persistor

Vert.x Java examples can be compiled and run on the fly. The Scala modules should have a similar option that allows Scala examples to be compiled on the fly and run. This would provide parity with Vert.x Java examples.

It's unclear whether this is already supported in ScalaVerticleFactory, so the first thing to do here would be to verify whether this already works. This class already has hooks with the Scala interpreter, so it'd be good to come up with an example/test that verifies this works as expected. For example, take one of the examples and see if you can run it with similar instructions to these:

vertx run MyApp.scala

If the code in the Scala verticle is not sufficient, one of the options to achieve this is to hook an SBT based Scala compiler, just like IntelliJ IDEA currently does.

eclipse-vertx/vert.x@f9afbdb

Thanks!

Since 2.1-M1 it is possible to send messages via the EventBus with timeouts. This should be implemented in Scala, too.

https://github.com/vert-x/mod-lang-scala/blob/master/src/main/scala/org/vertx/scala/core/package.scala#L75

Vertx Java would return time id to caller. This behavior is disappeared in scala version. The timer id is important for caller because it can be used to track what timers are running and scheduled at user's system.

The workaround for this is just use Java version for now like this.
https://github.com/vert-x/mod-lang-scala/blob/master/src/main/scala/org/vertx/scala/core/package.scala#L75

Traits can be used for the common SSL and TCP stuff that's used by NetServer/NetClient and HttpServer/HttpClient to reduce unnecessary code duplication.

See TCPSupport/SSLSupport in the Java API for the equivalent in Java.

A separate module containing an SBT Vert.x plugin is needed. This would enable Vert.x Scala applications to be run directly from the SBT console.

Just like Spray (via their SBT Revolver plugin) or Play 2 web apps, a subtask here would be to be able to be able to detect changes in the source files and be able to recompile and restart the Vert.x app on the fly.

While compiling this class,

class SockJSVerticle extends Verticle {

override def start(future: Future[Void]):Unit = {
start()
val ws = "/ws"
var defaultPort = 8080
val port = Play.maybeApplication.map(_.configuration.getInt("vertx.sockjs.port").get).getOrElse(defaultPort)
val server = vertx.createHttpServer
val permitted = new JsonArray()
permitted.add(new JsonObject()) // Let everything through
val sockServer = vertx.createSockJSServer(server).bridge(new JsonObject().putString("prefix", ws), permitted, permitted).asInstanceOf[SockJSServer]
// install a test app to echo
sockServer.installApp(new JsonObject().putString("prefix", "/echoapp")) {
(sock: SockJSSocket) => {
Pump.newPump(sock, sock).start()
}
}
server.listen(port, { ar =>
if (ar.succeeded()) {
future.setResult(null)
}
else {
future.setFailure(ar.cause())
}
})
}

}

I got this exception:

[ant:scalac] error: bad symbolic reference. A signature in Configuration.class refers to term typesafe
[ant:scalac] in package com which is not available.
[ant:scalac] It may be completely missing from the current classpath, or the version on
[ant:scalac] the classpath might be incompatible with the version used when compiling Configuration.class.
[ant:scalac] error:
[ant:scalac] while compiling: /Users/macbookpro/workspaces/vertx/src/main/scala/verticles/SockJSVerticle.scala
[ant:scalac] during phase: erasure
[ant:scalac] == Expanded type of tree ==
[ant:scalac]
[ant:scalac] ErasedValueType(org.vertx.scala.core.package.Vertx)

There are two instances of ScalaHttpTest in different packages, these should be renamed, moved or combined.

Here is an example to reading out some values from the container config:

This is how it looks now:

val config = container.config().obj

connection = config.get("connection").map(_.toString().toLowerCase) match {
  case Some("postgresql") => "postgresql"
  case Some("mysql") => "mysql"
  case None => "postgresql"
  case Some(x) => throw new IllegalArgumentException("unknown connection type " + x)
}

val address = config.getOrElse("address", "campudus.asyncdb")

This is how it looks like when I'm using the Vertx JsonObject:

val config = Option(new JsonObject(container.config().toString())).getOrElse(new JsonObject)

connection = config.getString("connection", "postgresql").toLowerCase match {
  case "postgresql" => "postgresql"
  case "mysql" => "mysql"
  case x => throw new IllegalArgumentException("unknown connection type " + x)
}

val address = config.getString("address", "campudus.asyncdb")

I think it makes sense to use the JsonObject provided by Vertx. It's more user-friendly right now and it would save a lot of conversions. If you want to provide a more Scala-ish API, I'd prefer a wrapper around Vertx' JsonObject and a toMap() method which returns an immutable map.

See also:
eclipse-vertx/vert.x@633ccaa

eclipse-vertx/vert.x@9d672ed

Thanks!

found : org.vertx.scala.core.eventbus.EventBus
required: org.vertx.java.core.eventbus.EventBus

lazy val eb = EventBus(vertx.eventBus)

I think it should requires scala one.

Can't start scala script with newest master. I tried running this code with "vertx run Server.scala":

import org.vertx.scala.core.net.NetSocket
import org.vertx.scala.core.streams.Pump

vertx.createNetServer().connectHandler({ socket: NetSocket =>
    Pump.createPump(socket, socket).start
}).listen(1234)

and got this error:

Try running file:/D:/FH/_Campudus_Praktika/Server.scala as script
<console>:7: error: object scala is not a member of package org.vertx
       import org.vertx.scala._, org.vertx.scala.core._, org.vertx.scala.core.http._
                        ^
<console>:7: error: object scala is not a member of package org.vertx
       import org.vertx.scala._, org.vertx.scala.core._, org.vertx.scala.core.http._
                                           ^
<console>:7: error: object scala is not a member of package org.vertx
       import org.vertx.scala._, org.vertx.scala.core._, org.vertx.scala.core.http._
                                                                   ^
Not a script, try running file:/D:/FH/_Campudus_Praktika/Server.scala as class
D:\FH\_Campudus_Praktika\Server.scala:4: error: expected class or object definition
vertx.createNetServer().connectHandler({ socket: NetSocket =>
^

This would enable us to write:

def start(p: Promise[Unit]) = {
  doSomethingAsyncReturningAFuture() map { result =>
    p.success()
  } recover { ex =>
    logger.error("problem at start up!", ex)
    p.failure()
  }
}

a) We wouldn't need the Future class at all.
b) It would be more towards the Scala-way
c) Users cannot overwrite the Futures failure handler during startup. This is safer than the Java API approach (hoping the dev doesn't do stupid things ;)).

Our build files are not standard and might cause us problems.

Effectively rebase with build files in https://github.com/vert-x/vertx-gradle-template

I don't like relying on SNAPSHOT versions, so it would be great if the current master could just be set to 0.1.0 and be released. :)

It would invite others to try out the scala mod, too. And as you can see in the mod-mysql-postgresql, it already works for a few tasks. ;)

Would be nicer to use.

Another thing that might be missing is a simple way (like req.cookie()) of getting the cookies sent by the client to the server. I couldn't see such a function in Vert.x core, though, so I'm not sure whether this was left out by intention.

We should apply function currying, where posssible, to enable more pleasant syntax, e.g.:

vertx.setPeriodic(1000) { timerID =>
  vertx.eventBus.publish("news-feed", "News from Java!")
}

instead of:

vertx.setPeriodic(1000, { timerID =>
  vertx.eventBus.publish("news-feed", "News from Java!")
})

In Java, you can specify .java as main and deploy .java source file directly. However, you can't use scala source directly. This following should be supported.

"main":"scala:demo/GameVerticle.scala",

See group question on the topic.

Discussion thread. Check for other similar situations in the code.

SockJSSocket should extend ReadStream[SockJSSocket] with WriteStream[SockJSSocket]

Anyone knows workaround?

... and also expose uri() method in ServerWebSocket

eclipse-vertx/vert.x@d207b6a

It should note general contributing guidelines, linking style, formatting...etc.

IIRC this is a leak, if you don't send a reply back from the server side. It would register a handler but that would never be executed.

I guess the default value should just be null and it be disregarded by Vert.x in the Java core. Not sure whether this is the best approach, though. Probably better use an Option and then call the according Java API function.

org.vertx.scala.core.http.HttpServerRequest uses Scala's collection.mutable.MultiMap which is not case insensitive, preventing headers to be correctly retrieved when the case in their names don't match.

In other vert.x langs, this works as expected, ie header names are case-insensitive.

I believe this is because vertx.runOnLoop() calls internal.runOnLoop instead of internal.runOnContext (with adaptation of the handler).

java.lang.StackOverflowError
    at org.vertx.scala.core.package$.Vertx(package.scala:43)
    at org.vertx.scala.core.package$Vertx$.runOnLoop$extension(package.scala:71)
    at org.vertx.scala.core.package$Vertx$.runOnLoop$extension(package.scala:71)
    at org.vertx.scala.core.package$Vertx$.runOnLoop$extension(package.scala:71)
    at org.vertx.scala.core.package$Vertx$.runOnLoop$extension(package.scala:71)
    at org.vertx.scala.core.package$Vertx$.runOnLoop$extension(package.scala:71)

Currently the API exposes the Handler class in various places, with an implicit conversion occurring externally. I think it would be preferable to expose a function parameter and do the conversion to a Handler internally, instead.

So replacing:

someMethod(foo: Handler[Bar]):Unit = { ... }

with:

someMethod(foo: Bar => Unit):Unit = { convertToHandler(foo) }

In our projects, we use Futures and Promises to get rid of the nested callbacks. It would be very nice to have them in the API directly instead of having to write them myself.

If you want to stay tied to the Vert.x API, this could also be done as an extra, includable module. Not sure whether this makes much sense, though.

eclipse-vertx/vert.x@cbbd951

Thanks!

Adjust Scala lang module ZIP name according to Tim's recommendations.