Differences

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

Link to this comparison view

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