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