Differences

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

Link to this comparison view

irc:1438120800 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[08:56:37] *** ChanServ sets mode: +o temporalfox
 +
 +[09:40:47] <​temporalfox>​ hi pmlopes
 +
 +[09:40:52] <​pmlopes>​ hi good morning
 +
 +[09:41:14] <​temporalfox>​ I wanted to check with you about some vertx-web option configuration
 +
 +[09:41:18] <​temporalfox>​ or maybe auth
 +
 +[09:41:22] <​pmlopes>​ sure
 +
 +[09:41:27] <​temporalfox>​ I remember there is one part that uses a java key store
 +
 +[09:41:54] <​temporalfox>​ it would be a good thing to have this part reuse the vertx-core similar options to configure certificates
 +
 +[09:42:06] <​temporalfox>​ becuase it supports java key stores but also other formats
 +
 +[09:42:14] <​temporalfox>​ pfx and pem files
 +
 +[09:42:31] <​temporalfox>​ do you think that's something feasible and we could open an issue for it ?
 +
 +[09:42:32] <​pmlopes>​ yes it is the auth, i used a keystore to keep all the algorithms and keys for the jwt signatures
 +
 +[09:43:56] <​pmlopes>​ so i need to be able to get a list of signatures: "​RS256",​ "​RS384",​ "​RS512",​ "​ES256",​ "​ES384",​ "​ES512"​ and MACs "​HS256",​ "​HS384",​ "​HS512"​
 +
 +[09:44:09] <​pmlopes>​ is there a way to have them all together in a pem file?
 +
 +[09:44:20] <​temporalfox>​ I don't know :-)
 +
 +[09:44:37] <​temporalfox>​ perhaps it does make only sense to use JksOptions object
 +
 +[09:44:48] <​temporalfox>​ the jks option allows to load from a path
 +
 +[09:44:51] <​pmlopes>​ most people using jwt will only need one, but the spec states that we should be able to handle any of those
 +
 +[09:44:52] <​temporalfox>​ but also from a buffer
 +
 +[09:46:02] <​pmlopes>​ ok, i can do that
 +
 +[09:47:08] <​temporalfox>​ just open an issue for it
 +
 +[09:47:14] <​temporalfox>​ and then we can see if that makes sense or not
 +
 +[09:48:12] <​pmlopes>​ yes, the pfx format is for certificates so i am afraid it won't work with the jwt use case since we need signatures and macs so moving to JksOptions makes sence to keep consistency across the code
 +
 +[09:48:28] <​temporalfox>​ ok
 +
 +[09:48:33] <​temporalfox>​ good to know
 +
 +[09:48:52] <​pmlopes>​ now, does the jksoptions allow to read jceks format? because the basic jks does not allow storing macs...
 +
 +[09:49:08] <​temporalfox>​ the options just provides a path to a store or a Buffer of the store
 +
 +[09:49:16] <​temporalfox>​ it does not handle loading per se
 +
 +[09:49:59] <​temporalfox>​ I think the point here is to provide a consistent api for the developer
 +
 +[09:50:08] <​temporalfox>​ then if we can make some loading code shared it's good too
 +
 +[09:50:34] <​pmlopes>​ yes but to be able to load a jceks you need to instantiate a keystore like: KeyStore.getInstance("​jceks"​) otherwise it will pick the system default "​jks"​ and not work...
 +
 +[10:05:49] <​temporalfox>​ ok
 +
 +[10:47:47] *** ChanServ sets mode: +o purplefox
 +
 +[12:18:28] <​Nash>​ for example hot code swapping in erlang/OTP
 +
 +[12:43:42] <​Sticky>​ temporalfox:​ cescoffier thanks for the replies yesterday, got called away before seeing them.
 +
 +[13:55:04] <​D-Spair>​ Hi all... I'm working on a blog post about Vert.x 3 and I got an interesting error when trying to run some code I updated from 3.0.0-M4... WARNING: No such property to configure on options: io.vertx.core.DeploymentOptions.redeploy
 +
 +[13:55:22] <​D-Spair>​ Did automatic redeploy get removed from Vert.x 3.0.0 in the final release?
 +
 +[13:55:38] <​D-Spair>​ I looked that the source for DeploymentOptions and it is not there anymore!
 +
 +[13:59:38] <​s0va>​ D-Spair: i think that this works only for js, ruby, python and so on
 +
 +[14:00:00] <​D-Spair>​ s0va:  It used to work for Java too...
 +
 +[14:00:01] <​s0va>​ doesn'​t work for me in pure java in 2.1.x
 +
 +[14:00:18] <​D-Spair>​ For Vert.x 3 I used it in the milestone releases..
 +
 +[14:00:42] <​D-Spair>​ The only restraint was that you couldn'​t redeploy the initial Verticle...
 +
 +[14:00:57] <​D-Spair>​ All other programmatically loaded verticles would redeploy.
 +
 +[14:02:10] <​s0va>​ oh, nice, i didn't know that
 +
 +[14:02:42] <​D-Spair>​ s0va:  Except, now it's not there anymore..
 +
 +[14:03:15] <​D-Spair>​ The only reference to "​redeploy"​ in vertx-core is now related HA
 +
 +[14:03:29] <​D-Spair>​ I am very sad.... :​disappointed:​
 +
 +[14:03:59] <​s0va>​ looks like removed option
 +
 +[14:04:04] <​s0va>​ yep
 +
 +[14:05:58] <​Nash>​ anybody know about hot reloading of code?
 +
 +[14:06:14] <​D-Spair>​ Nash:  A little...
 +
 +[14:06:55] <​Nash>​ great.. how does it work in vertx?
 +
 +[14:07:10] <​D-Spair>​ Nash:  Depends on the language you are deploying...
 +
 +[14:07:23] <​Nash>​ JAVA
 +
 +[14:07:40] <​D-Spair>​ For Java, you can load updated code from a maven repo programmatically
 +
 +[14:08:24] <​D-Spair>​ For JavaScript, you can do something similar for NPM repositories...
 +
 +[14:08:30] <​Nash>​ maven repo? no i am talking about live code swapping like erlang. the code change gets deployed automatically.
 +
 +[14:09:06] <​D-Spair>​ Nash: So am I... A running Vert.x instance can download and deploy code directly from a Maven repo...
 +
 +[14:10:17] <​D-Spair>​ So, if you are running foo-1.0.0 and want to deploy foo-1.1.0, you can do "​vertx.deployVerticle("​maven:<​groupId>:<​artifactId>:<​version>:​clazzName"​);​
 +
 +[14:10:43] <​Nash>​ oh ok.but i am talking about redeployement in real time. like one verticle is running locally inside vertx instance. and that verticle code changes and that changed code automaticlly gets updated without restarting verticle
 +
 +[14:10:55] <​D-Spair>​ You have to expose that capability programmatically though... I usually write a REST endpoint where I can send in the Maven coordinates.
 +
 +[14:11:24] <​D-Spair>​ Nash: That feature was apparently removed in the final release of 3.0.0
 +
 +[14:11:38] <​Nash>​ oh. ok. thats bad. :(
 +
 +[14:11:40] <​D-Spair>​ It's what I was just talking about above...
 +
 +[14:11:47] <​Nash>​ it is a must have feature for production apps
 +
 +[14:12:04] <​D-Spair>​ Nash: Many people have done without that for many years...
 +
 +[14:13:20] <​Nash>​ even i do toady in production. but it is not feasible when you have  single java file modified and you need to restart/​reload entire application
 +
 +[14:14:14] <​D-Spair>​ Nash: Again, you can use the NPM or Maven deployment method, which is more "​DevOps"/"​Continuous Delivery"​ oriented anyhow...
 +
 +[14:14:31] <​Nash>​ also it is very time consuming when you have 5-7 Re-deployments in day in production !
 +
 +[14:15:24] <​Nash>​ i got your point about automatic deployment. but what i mean to say is that automatic deployment with "​ZERO"​ down time
 +
 +[14:15:40] <​D-Spair>​ If you have 5-7 deployments a day in production, I would have to say that is a smell..
 +
 +[14:16:04] <​D-Spair>​ Nash:  The Maven/NPM methods do not incur downtime...
 +
 +[14:16:21] <​Nash>​ oh ok. then i must check that methods
 +
 +[14:18:06] <​D-Spair>​ Nash: https://​github.com/​vert-x3/​vertx-maven-service-factory
 +
 +[14:18:22] <​Nash>​ ok thanx for helping me out
 +
 +[14:20:59] <​Nash>​ i first checked this :​https://​groups.google.com/​forum/#​!topic/​vertx/​4bFaLj0V3_M
 +
 +[15:47:30] <​cescoffier>​ pmlopes - about the thymeleaf example, I would like to automate its execution
 +
 +[15:48:07] <​pmlopes>​ yes, you can get the generated html and grep for a piece of text?
 +
 +[15:53:32] <​cescoffier>​ much better, I'm going to read the page using phantom js et query some element
 +
 +[15:54:05] <​cescoffier>​ it's how I get most of them done: https://​vertx.ci.cloudbees.com/​view/​vert.x-3/​job/​vertx3-examples-it/​Web_Examples_Report/​
 +
 +[15:55:20] <​cescoffier>​ pmlopes, temporalfox - something went terribly wrong in the last jgroup cluster manager build, cancelling it
 +
 +[15:55:31] <​temporalfox>​ ok
 +
 +[15:55:38] <​temporalfox>​ I fixed a couple of jenkins builds yesterday
 +
 +[15:55:46] <​temporalfox>​ that were not up to date
 +
 +[15:55:52] <​temporalfox>​ vertx-auth
 +
 +[16:00:01] <​cescoffier>​ here something went bad when starting the cluster manager
 +
 +[16:00:17] <​cescoffier>​ it did not start well so all calls timed out
 +
 +[20:43:45] <​cescoffier>​ pmlopes: did you know https://​github.com/​saffron-technology/​vertx-eventbusbridge