Differences

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

Link to this comparison view

irc:1465682400 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[14:10:17] <​BadApe>​ hello, what do i need to include in my pom.xml to support different algorithms?
 +
 +[17:45:29] <​temporalfox>​ BadApe hi, what do you mean ?
 +
 +[17:47:01] <​BadApe>​ hi temporalfox i tried to use SHA-512 with jwt, i was told it wasn't supported, so i am having a heck of a time trying to figure out what i need to include
 +
 +[17:47:45] <​temporalfox>​ BadApe have you checked the Vert.x examples ?
 +
 +[17:48:11] <​BadApe>​ i will now :D
 +
 +[17:50:31] <​BadApe>​ https://​github.com/​vert-x3/​vertx-examples/​blob/​master/​web-examples/​src/​main/​java/​io/​vertx/​example/​web/​jwt/​Server.java doesn'​t help much
 +
 +[19:12:25] <​AlexLehm>​ cescoffier: I have added a description about the proxies to the example classes, is that working for you?
 +
 +[19:26:42] <​cescoffier>​ Hi Alex, yes it looks good
 +
 +[19:26:54] <​cescoffier>​ AlexLehm - need to check how to automate these examples (meaning that I should be able to run them on a bare machine is a reproducible way and check the result)
 +
 +[19:27:49] <​AlexLehm>​ can you provision additional package on a machine? For squid that should work out of the box, for the dante-server you need to overwrite the config file, but I think that should work
 +
 +[19:28:02] <​cescoffier>​ on windows ?
 +
 +[19:32:11] <​cescoffier>​ For one I believe we could "​Fake"​ a proxy with a simple verticle
 +
 +[19:36:31] <​AlexLehm>​ on windows, it works to install the squid package, I use that for testing, with the socks proxy I didn't figure it out yet
 +
 +[19:37:04] <​AlexLehm>​ there is a testing proxy for http and socks in the vertx-core test code, you can easily turn that into a verticle (i can try if you like)
 +
 +[19:58:46] <​cescoffier>​ AlexLehm : that would be awesome !
 +
 +[20:10:06] <​AlexLehm>​ or can you use ssh on the test machine to somewhere, with putty that would work in windows?
 +
 +[20:59:42] <​cescoffier>​ AlexLehm : hard to automate on  bare machine
 +
 +[21:02:49] <​AlexLehm>​ yes you're right
 +
 +[21:59:01] <​Yakabu>​ Hi. Is it possible to deploy changed/new verticles from a vert.x instance? E.g. if I decide to create a new verticle, can I deploy that at runtime without restarting the vert.x instance?
 +
 +[22:00:55] <​Sticky>​ basicly all verticles are deployed at run time
 +
 +[22:01:27] <​Yakabu>​ Ya, can I make a change to a verticle and deploy the changed version?
 +
 +[22:01:33] <​Sticky>​ yes
 +
 +[22:01:42] <​Yakabu>​ Oooh, how? :)
 +
 +[22:02:04] <​Yakabu>​ I tried with a local maven repository but it seems it loads the classes on start, so doesn'​t update
 +
 +[22:02:24] <​Sticky>​ well when you say "​change"​ what do you want to change?
 +
 +[22:02:49] <​Yakabu>​ Essentially create a new verticle class and deloy that
 +
 +[22:03:01] <​Yakabu>​ deploy*
 +
 +[22:03:46] <​Sticky>​ so modifying classes will have to be done with bytecode transformation,​ that is pretty much nothing to do with vertx, look at things like ASM for that
 +
 +[22:04:29] <​Yakabu>​ Hmm, I don't want to modify classes at runtime. I just want to deploy a newly created verticle
 +
 +[22:05:02] <​Sticky>​ but once you have a class you want to deploy you can then just do vertx.deployVerticle(new MyNewVerticel())
 +
 +[22:05:07] <​Yakabu>​ E.g. I start with my vert.x instance with verticle1 and verticle2. some time later, I code verticle3 and decide I want to deploy that.
 +
 +[22:05:19] <​Yakabu>​ Yes but that requires that the class is on the classpath
 +
 +[22:05:44] <​Sticky>​ ahh right, so your problem is you want to add classes to the classpath at runtime?
 +
 +[22:06:21] <​Yakabu>​ Well, I'm not 100% sure on how vert.x deals with deploying verticles. But if that is how I can deploy different verticles after launching my vert.x instance, then yes
 +
 +[22:08:41] <​Yakabu>​ My thinking was that if I use a maven repository and simply update that maven repository, then it should work
 +
 +[22:09:31] <​Sticky>​ that is not really how maven works
 +
 +[22:10:43] <​Yakabu>​ I know that isn't how maven works in the conventional way, but I thought vert.x would do some magic to load classes at runtime
 +
 +[22:11:43] <​Yakabu>​ https://​github.com/​vert-x3/​vertx-examples/​tree/​master/​maven-service-factory-examples
 +
 +[22:13:36] <​Sticky>​ I may be wrong but as far as I know vertx has nothing out the box to do this
 +
 +[22:14:24] <​Yakabu>​ :(
 +
 +[22:15:56] <​Sticky>​ but even if it doesnt, it is technically possible, just you will have to code it a bit yourself
 +
 +[22:16:53] <​Sticky>​ but obviously with the unhelpful question of...why do you want to do this?
 +
 +[22:17:30] <​Yakabu>​ Well it isn't absolutely necessary for what I want to do, since I can just cluster the vert.x instances
 +
 +[22:17:48] <​Yakabu>​ But I kinda wanted to have a single vert.x instance with a bunch of verticles, so I don't need to cluster
 +
 +[22:18:28] <​Yakabu>​ And then the way I imagined it is that I can make changes to verticles, then redeploy them on the same instance
 +
 +[22:18:31] <​Sticky>​ so why cant you restart the jvm when you need to update the code?
 +
 +[22:18:38] <​Yakabu>​ because it's stateful
 +
 +[22:18:59] <​Yakabu>​ I don't want to go through the hassle of serializing state and such
 +
 +[22:19:19] <​Sticky>​ hmmmm, I assume this is a toy application?​
 +
 +[22:19:41] <​Yakabu>​ it's for personal use
 +
 +[22:19:52] <​Sticky>​ ok, fair enough