Approvals: 0/1
[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