[00:19:37] <NeuwDk> Hello. Is there a way to set a file to get through the template engine when requesting / on the route? I have a redirect workaround right now, but it is not very pretty. Any help is very appreciated (I am coding in Ruby)

[11:04:11] <purplefox> temporalfox: pmlopes seems like i've screwed something and caused vertx-core build to fail… investigating

[11:04:40] <temporalfox> ok

[11:04:53] <temporalfox> what kind of stuff ?

[11:05:23] <purplefox> something to do with ssl

[11:05:28] <purplefox> it's failing on ci

[11:05:30] <purplefox> and locally

[11:05:35] <purplefox> can't quite work out what is wrong yet

[11:06:39] <purplefox> it's a bit weird

[11:06:47] <purplefox> as it started failing on the 5th, but last commit is on the 3rd

[11:06:55] <purplefox> but it fails locally too

[11:07:23] <purplefox> lol maybe there's some weird bug in the ssl impl that only happens after 4th july? ;)

[11:08:58] <aesteve> USA strikes again ! ;)

[11:09:18] <purplefox> hmm, i wonder if the test certs we use in the test suite have become invalid? (expired)

[11:16:07] <purplefox> temporalfox: yes i think certs have expired

[11:16:58] <purplefox> temporalfox: I think it's the pem ones

[11:17:23] <purplefox> temporalfox: actually it reports expired 11 months ago

[11:17:34] <purplefox> but i think there is an 11 month grace period (?)

[11:17:47] <temporalfox> ok

[11:17:53] <purplefox> [email protected] ~/projects/vert-x3/vert.x/src/test/resources/tls/ca $ openssl x509 -enddate -noout -in ca-cert.pem

[11:17:54] <purplefox> notAfter=Aug 3 13:15:09 2014 GMT

[11:18:18] <purplefox> tbh, I'm no expert on this certs, and no idea how to create them

[11:19:17] <temporalfox> there is an howto text file you started

[11:19:42] <temporalfox> and I added info there for the other ones

[11:19:59] <temporalfox> ssl.txt

[11:20:43] <temporalfox> I'm having issues generating ceylon options with ssl options in HttpServerOptions

[11:30:10] <cescoffier> purplefox: I can have a look to the certificate stuff

[11:30:10] <purplefox> temporalfox: np

[11:30:17] <cescoffier> I did it a couple of weeks ago

[11:30:26] <purplefox> cescoffier: ah, great. that would be awesome :)

[11:30:32] <temporalfox> perhaps it would be good to transform the txt file

[11:30:44] <temporalfox> into a bash script

[11:30:44] <temporalfox> with comments

[11:30:45] <cescoffier> just back from my medical check….

[11:30:53] <cescoffier> well, I've that somewhere

[11:31:15] <cescoffier> purplefox: do we have an issue for this ?

[11:31:25] <purplefox> temporalfox: yes, that would make a lot of sense if it would be automated

[11:31:45] <purplefox> but we should also set the expiry (if possible?) like 100 years in the future so hopefully this doesn't happen again ;)

[11:32:12] <cescoffier> temporalfox: thanks for the ext-parent release, gonna update the extension projects

[11:32:55] <temporalfox> what is weird is that pem expires 11 months ago

[11:33:02] <temporalfox> and I did create these files last year

[11:33:10] <aesteve> temporalfox: I got a very small issue with service-proxy : it has unused imports. Not a big deal but my IDE was configured to mark unused imports as an error so I got huge warnings every time I launch a test for example

[11:33:11] <temporalfox> and I don't think I set a “one month” expiration date

[11:33:25] <cescoffier> purplefox: would 3650 be ok ? (10 years)

[11:34:05] <cescoffier> aesteve: yes, the unuesd import are 'kind' of expected

[11:34:06] <purplefox> temporalfox: maybe there's a low default, or maybe you copied the jks ones that I created with a low date? ;)

[11:34:12] <cescoffier> it's because they are generated from the import of the service class

[11:34:35] <temporalfox> purplefox I think I reused the same certificates actually as you said

[11:34:42] <temporalfox> because it makes test easier

[11:34:47] <temporalfox> so I can do combo

[11:34:55] <temporalfox> pem on server / pfx on client

[11:34:57] <temporalfox> etc…

[11:35:40] <purplefox> temporalfox: so it IS my fault! dammit ;)

[11:36:16] <temporalfox> sooner or later it expires anyway

[11:38:09] <purplefox> temporalfox: we should just set the date on our machines back to the same day every morning, like groundhog day. problem solved!

[11:39:17] <cescoffier> purplefox: so actually not an issue ?

[11:41:05] <purplefox> cescoffier: lol, i guess not!

[11:41:05] <cescoffier>

[11:42:24] <cescoffier> purplefox: there is a couple of issue marked as deferred that are about the former openshift cartridge.

[11:42:50] <cescoffier> I can have a look if you want

[11:43:09] <cescoffier> these issues should be marked as vert.x 2 and not deferred

[11:43:19] <purplefox> agreed

[11:43:32] <purplefox> regarding the question of what do we do with the old vert.x 2 modules

[11:43:38] <purplefox> and related projects

[11:43:48] <purplefox> i don't think we should implement any new features

[11:44:08] <purplefox> but we can consider doing bug fix maintenance releases like we do with vertx-core 2.x branch

[11:44:29] <purplefox> but we have to be careful it doesn't become a big resource strain on us

[11:44:54] <purplefox> my opinion is to avoid doing stuff unless it's really necessary (e.g. critical bugs, security issues etc)

[11:45:30] <cescoffier> I agree, we should not implement new features, but if there is some pending release (i.e. modules ready for being released as a bug fix release) we should do it

[11:45:33] <purplefox> if possible, it's preferable to push people towards the v3 stuff

[11:45:56] <cescoffier> and in the release announcement emphase the fact that people should use vert.x 3

[11:46:03] <purplefox> yeah, i think that's fine as long as its not much work

[11:46:15] <purplefox> another thing we can consider is making community members the owners of the module

[11:46:23] <purplefox> so they can handle the release themselves

[11:46:36] <purplefox> e.g. we did this with the mod-mongo-persistor module

[11:46:41] <purplefox> and various language implementations

[11:47:11] <purplefox> so if someone is saying “hey we really need a release”, it might be worth considering saying “are you interested in being the maintainer for this module?”

[11:48:28] <cescoffier> that would be cool

[11:48:44] <cescoffier> how does the release process work for v2 ?

[11:48:57] <purplefox> there are a few modules, e.g. the vertx-maven (v2 maven plugin + archetype) i would like to do this with

[11:49:01] <cescoffier> for instance do we need to had them to the Sonatype OSS Group to let them deploy ?

[11:49:09] <purplefox> release process for v2 was very simple

[11:49:15] <purplefox> basically, when it's ready

[11:49:19] <purplefox> tag it

[11:49:24] <purplefox> then i did a mvn deploy

[11:49:34] <purplefox> then manually promote from the oss.sonatype web UI

[11:49:40] <purplefox> that's pretty much it

[11:50:25] <purplefox> yep we upload to oss.sonatype

[11:50:40] <purplefox> so no maven release plugin

[11:50:42] <purplefox> just basic mvn deploy

[11:51:11] <purplefox> for these modules there's usually just one artifact to release so it's pretty straightforward

[11:53:37] <cescoffier> so, you still do the Sonatype OSS stuff, you would delegate only the “Create the tag” action

[11:55:01] <purplefox> sure, but i can also add you to the io.vertx group so you have rights to push

[11:55:35] <cescoffier> well if you want, I already have an account

[11:55:47] <purplefox> actually we already have several community members with io.vertx push rights

[11:55:50] <purplefox> so this is pretty normal

[11:56:38] <purplefox> what's your sonatype username?

[12:02:52] <purplefox> cescoffier: basically we have a request page here we can get io.vertx rights added. as you can see from previous comments there are quite a few people with io.vertx push rights :) https://issues.sonatype.org/browse/OSSRH-3411?jql=text%20~%20%22vert.x%22

[12:03:19] <purplefox> at some point you'll need this anyway to do a release

[12:04:05] <cescoffier> as you are the owner you need to ask. My account is clement.escoffier

[12:04:26] <cescoffier> (if I would ask, Jordi will need a confirmation from you)

[12:04:52] <purplefox> ok done

[12:05:12] <cescoffier> thanks

[12:05:13] <purplefox> jordi=joel orlina?

[12:05:23] <cescoffier> yes

[12:05:37] <purplefox> this guy is always very helpful

[12:05:45] <cescoffier> yes, and very reactive

[12:05:51] <purplefox> +1

[12:06:15] <cescoffier> when they set up this oss sonatype, he was really busy, but so reactive

[12:06:18] <cescoffier> amazing !

[13:27:04] <NeuwDk> Hello out there. I was wondering if there is a way to change the path in a routingContext, so you could get a template to handle /. So fx router.route(“/”).handler() { |routingContext| routingContext.request().path(“/cheat-template-engine”) routingContext.next() }. Is it possible?

[14:23:00] <cescoffier> temporalfox: are you around ?

[14:24:44] <temporalfox> yes

[14:25:21] <cescoffier> in the reactive-stream projects the documentation is generated into target/docs/vertx-core

[14:25:35] <cescoffier> shouldn't it be target/docs/vertx-reactive/streams ?

[14:25:48] <temporalfox> I think it should be indeed

[14:25:49] <cescoffier> vertx-reactive-steams

[14:26:04] <temporalfox> why does it create wrong doc ?

[14:26:07] <temporalfox> well first

[14:26:10] <temporalfox> it's not a polyglot project

[14:26:23] <cescoffier> nope it's not a polyglot project

[14:26:47] <cescoffier> https://github.com/vert-x3/vertx-reactive-streams/blob/master/pom.xml#L144

[14:26:59] <cescoffier> I'm surprise the web site links work

[14:27:10] <cescoffier> maybe some magic happening the the stack project

[14:27:17] <temporalfox> maybe that michel did some magic

[14:27:27] <temporalfox> or stack

[14:27:31] <temporalfox> so for javadoc

[14:27:35] <temporalfox> javadoc is rebuilt

[14:27:45] <temporalfox> since we get an aggreaated one

[14:29:49] <cescoffier> yes, something weird happening here, it should not work

[14:30:05] <cescoffier> will update the directory and investigate

[14:36:47] <temporalfox> ok

[16:05:27] <aesteve> temporalfox: https://github.com/aesteve/vertx-nubes/blob/master/docs/RPC.md wdyt ?

[16:12:47] <cristianmiranda> Hi guys, I'm trying to setup slf4j logging into my Vertx 3 app. I've added the maven dependencies (slf4j-api, slf4j-log4j12, log4j), created the log4j.properties file in my src/main/resources and added the following when running the app (-Dvertx.logger-delegate-factory-class-name=io.vertx.core.logging.impl.SLF4JLogDelegateFactory).

[16:12:57] <cristianmiranda> But my log file doesn't get created

[16:13:09] <cristianmiranda> log4j.rootLogger=TRACE, stdout

[16:13:10] <cristianmiranda> log4j.appender.stdout=org.apache.log4j.RollingFileAppender

[16:13:10] <cristianmiranda> log4j.appender.stdout.MaxFileSize=2MB

[16:13:10] <cristianmiranda> log4j.appender.stdout.MaxBackupIndex=2

[16:13:10] <cristianmiranda> log4j.appender.stdout.File=logs/console.log

[16:13:11] <cristianmiranda> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout

[16:13:17] <cristianmiranda> Any ideas? Thanks in advance

[16:37:29] <cescoffier> cristianmiranda: check that the log4j.properties file is in your classpath

[16:39:08] <Narigo> hi there, is there roadmap for 3.1? i mean _when_ should it be released.. since there are still some open questions regarding mysql/postgresql..

[16:42:29] <cescoffier> Narigo: the roadmap is going to be defined soon (this week). mysql/postres is (for now) on the roadmap. It is going to be rewritten in java.

[16:43:51] <Narigo> cescoffier, i guess i shall do that (i wrote the scala version ;)), so i'd like to know why things were not working as expected… see https://github.com/vert-x3/vertx-mysql-postgresql-client/issues/20

[16:46:01] <cristianmiranda> cescoffier: That was the problem :) Thank you

[16:47:43] <cescoffier> Narigo: I didn't have a deep look but for instance in the AsyncSQLConnectionImpl, the inTransaction field can be modified by different thread at the same time

[16:48:24] <cescoffier> Narigo: same thing in AsyncConnectionPool

[16:52:38] <Narigo> cescoffier, but the connection should only be used by a single thread..?

[16:53:58] <cescoffier> Narigo: not in the case of a shared client

[16:54:46] <Narigo> cescoffier, ah ok. so after changing it from service to client, we should have had a look for thread safety

[16:55:01] <cescoffier> yes

[16:55:59] <cescoffier> Narigo: the conversion to Java task is here: https://github.com/vert-x3/vertx-mysql-postgresql-client/issues/19 (and assigned to me )

[16:56:49] <Narigo> :( and i thought we got rid of all the threading issues just by using vertx :(

[16:57:29] <cescoffier> Narigo: not completely

[16:57:53] <cescoffier> temporalfox: eh eh just found why it's working. The directory that should reflect the project name is not in the zip file, so it could be anything.

[16:58:34] <Narigo> cescoffier, so no need for me to do anything with mysql/postgresql anymore?

[16:58:51] <Narigo> or did you self-assign because no one took it yet?

[16:58:55] <cescoffier> Narigo: feel free to do it if you want

[16:59:10] <Narigo> cescoffier, that depends on when you want/need it ;)

[16:59:36] <cescoffier> Narigo: hum, probably not before middle of August

[16:59:56] <cescoffier> (I don't see a 3.1 hapening before)

[17:00:59] <Narigo> cescoffier, if you don't plan to start during the next two weeks, i might be able to do it or at least help you porting it

[17:01:50] <cescoffier> Narigo: ok cool

[17:02:08] <cescoffier> let's do that (don't worry, I've enough work to keep me busy until that )

[17:02:23] <Narigo> cescoffier, i'll definitely need help to make it thread safe then ;)

[17:02:37] <cescoffier> Narigo: I will be around

[17:02:56] <Narigo> and i guess an AsyncObjectPool<X> would be a generally nice thing to have somewhere…

[22:51:34] <diega> Hi all, is it me or https://github.com/eclipse/vert.x/blob/master/src/main/java/io/vertx/core/impl/FileResolver.java#L56 seems to be wrong? It looks like it'll always return false, making ENABLE_CACHING always true

[22:52:39] <diega> this may be the reason for the problem here https://groups.google.com/d/msg/vertx/ANjSXoVN_Ws/EKqNJPF0vk0J

[23:15:31] <AlexLehm> shouldn't that be -Dproperty=true

[23:24:17] <AlexLehm> ok, actually no, this was different before, looks like it doesn't evaluate the system property anymore

[23:25:13] <AlexLehm> diega, maybe you can create an issue for that