[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