Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1446159600 [2017/05/27 13:44] (current)
Line 1: Line 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