[08:56:13] *** ChanServ sets mode: +o temporalfox

[16:23:02] <SLED> Hi all

[16:23:15] <SLED> I got an issue when I launch vertx

[16:23:23] <SLED> Erreur : impossible de trouver ou charger la classe principale org.vertx.java.platform.impl.cli.Starter

[16:24:03] <SLED> Or “Error : Failed to find or launch org.vertx.java.platform.impl.cli.Starter”

[16:24:09] <SLED> Can Someone help me on that?

[16:24:48] <SLED> I though it was my vertx which was break, but it seems it was not this

[16:45:10] <cescoffier> it looks like you are using vert.x 2 ?

[17:21:39] <SLED> @cescoffier Yes

[17:21:48] <SLED> cescoffier: Yes

[17:22:19] <cescoffier> from the error message you should check that the jar containing the Starter class is in the classpath

[17:22:51] <SLED> cescoffier: I checked it and it contained it

[17:22:54] <SLED> cescoffier: :/

[22:03:21] <riscado> Hi everyone

[22:03:41] <riscado> I've been playing around with file uploads during this week

[22:03:56] <riscado> and it looks as though HttpServerFileUpload

[22:04:00] <riscado> readstream

[22:04:06] <riscado> never has a set size

[22:04:33] <riscado> is this a known issue?

[22:18:36] <temporal_> hi riscado can you report it has an issue on bugzilla tracker of vertx ?

[22:19:45] <riscado> I can

[22:19:56] <riscado> but I wanted to make sure that it is indeed an issue

[22:19:59] <riscado> before reporting

[22:21:39] <riscado> I've tried pumping data from the HttpServerFileUpload to the HttpClientRequest I'm building for Amazon S3

[22:21:58] <riscado> and using the request headers Content-Length to get the size

[22:22:19] <riscado> but apparently the size differs from the bytes contained with the FileUpload

[22:22:30] <riscado> and therefore S3 returns a 400 response

[22:22:55] <riscado> HttpServerFileUpload should the correct source to fetch the real Content-Length

[22:25:04] <riscado> it looks as though the size is always lazily calculated

[22:25:43] <riscado> which seems to be intentional but not good when you need to know the size beforehand

[22:41:56] <AlexLehm> riscado: the size may not be known beforehand I think, you may have to use chunked encoding for the upload to avoid issues with that

[22:42:30] <riscado> amazon S3 does not support chunked encoding

[22:42:33] <riscado> unfortunately

[22:42:34] <AlexLehm> if amazon upload supports chunked

[22:42:35] <AlexLehm> ah ok

[22:42:39] <riscado> :(

[22:43:24] <AlexLehm> if you are reading a http POST, i think the size is not known, since it is a application/multipart-www stream (or whatever the correct content type is)

[22:43:55] <riscado> it will be a form-data multipart request

[22:44:13] <riscado> the client will usually include a Content-Length in the request

[22:44:29] <AlexLehm> yes, that that is not the size of the file I think

[22:44:31] <riscado> however the content-length of the original request

[22:44:52] <riscado> doesn't seem to be the same as the content pumped through the HttpServerFileUpload

[22:45:01] <riscado> hence the 400 response by amazon

[22:45:13] <riscado> so not really sure how to deal with this issue

[22:45:34] <riscado> I do have code

[22:45:41] <riscado> if anyone cares to have a look

[22:46:08] <riscado> https://github.com/brunoriscado/vertx-S3-client/

[22:46:20] <riscado> I forgot to push the gradle dependencies file

[22:46:26] <riscado> but I'll add it this weekend

[22:53:18] <AlexLehm> maybe you can write a unit test that shows the behaviour without using the amazon as backend

[22:53:32] <AlexLehm> if you just assert the size you expect and the size that is received

[22:54:35] <AlexLehm> as Tim would say: do you have a reproducer?

[22:55:58] <riscado> I do

[22:56:01] <riscado> actually

[22:56:45] <riscado> but it's a integration test

[22:56:54] <riscado> but that's fine

[22:56:59] <riscado> I can write a simple unit test

[22:57:10] <riscado> that does the same thing

[22:57:23] <riscado> I guess that might be more useful

[22:57:45] <riscado> I'll add it during the weekend, thanks for the suggestion

[23:47:51] <AlexLehm> should NetSocket.upgradeToSsl throw exceptions or are these supposed to go to the exception handler if there is one? I had a file not found error on my jks key file and that throws an exception, which i didn't quite expect

[23:50:26] <riscado> haven't used that one, so can't quite help you there, my apologies