Differences

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

Link to this comparison view

irc:1463522400 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[09:58:21] <​LostCoder>​ Anyone know about the annotation processor for proxies in maven?
 +
 +[10:02:12] <​LostCoder>​ There seems to be a bug when using 3.5.1 of the maven compiler plugin
 +
 +[10:02:30] <​LostCoder>​ (3.5 and earlier work)
 +
 +[10:04:13] <​LostCoder>​ Im specifically talking about the @ProxyGen annotation
 +
 +[10:04:58] <​LostCoder>​ if the source files have been generated (from a previous compile) then the class files are not generated.
 +
 +[10:05:15] <​LostCoder>​ if I delete the source files, then the source files are generated and the class files.
 +
 +[10:05:46] <​LostCoder>​ so doing mvn clean install * 2  (the second time does not produce the proxy class files).
 +
 +[13:45:03] <​temporal_>​ LostCoder yes I think you need to clean first
 +
 +[13:45:08] <​temporal_>​ but it's a java compiler thing
 +
 +[13:45:14] <​temporal_>​ not related to codegen
 +
 +[13:56:07] <​LostCoder>​ I think its a bug introduced in maven 3.5.1
 +
 +[13:57:33] <​LostCoder>​ https://​issues.apache.org/​jira/​browse/​MCOMPILER-240 ​ (that is "​fixed"​) and it seems to have broken how vertx uses it
 +
 +[13:57:43] <​LostCoder>​ (copied from vertx examples etc)
 +
 +[14:41:56] *** ChanServ sets mode: +o temporalfox
 +
 +[15:58:23] <​skullcrasher>​ is there a possibilty to set my own DeploymentManager on vertx cluster start?
 +
 +[16:03:32] *** ChanServ sets mode: +o temporalfox
 +
 +[16:18:20] <​skullcrasher>​ or HaManager
 +
 +[16:24:58] <​ftavares>​ hi
 +
 +[16:28:11] <​skullcrasher>​ hi
 +
 +[16:32:59] <​ftavares>​ I'd like to know if there is an equivalent of Vert.x Rx provinding a "​CompletableFuture"​-ified API ?
 +
 +[16:45:43] <​skullcrasher>​ temporalfox,​ is there any possibilty to replace HAManager or DeploymentManager with my own implementation?​ We have problems getting "​total"​ verticle isolation with our own IsolationClassloader implementation
 +
 +[16:46:11] <​temporalfox>​ no you can't right now I htink
 +
 +[16:46:28] <​skullcrasher>​ until now we just "​hooked"​ our classloader into the chain, and for a regular deploy it seems to work. Problems now arise with the -ha option and automatic redeploy from HAManager
 +
 +[16:46:32] <​skullcrasher>​ ah ok :/ damn
 +
 +[16:46:51] <​skullcrasher>​ so we need to play with a fork of vertx core?
 +
 +[16:46:56] <​temporalfox>​ lol
 +
 +[16:46:58] <​temporalfox>​ again ?
 +
 +[16:47:11] <​temporalfox>​ what's your fundamental problem ?
 +
 +[16:47:12] <​skullcrasher>​ ?
 +
 +[16:47:35] <​skullcrasher>​ it seems there is no "​total"​ isolation between verticles
 +
 +[16:47:49] <​temporalfox>​ what do you mean by total isolation ?
 +
 +[16:47:52] <​skullcrasher>​ we want our verticles to be fat jars with all dependencies loaded from their jar file
 +
 +[16:48:00] <​temporalfox>​ that each verticle class has not the same class than the other verticles ?
 +
 +[16:48:11] <​temporalfox>​ even though they have the same name ?
 +
 +[16:48:42] <​skullcrasher>​ yes. actually we want to isolate all classes/​files that are in the jarfile
 +
 +[16:49:08] <​skullcrasher>​ so that only vertx core and java core are provided by the vertx instance
 +
 +[16:49:20] <​skullcrasher>​ and everything else hast to be in every deployed jar verticle
 +
 +[16:50:29] <​skullcrasher>​ as far as we debugged, this is currently not possible
 +
 +[16:50:46] <​skullcrasher> ​ but "​total"​ isolation is maybe a bit bad described :P
 +
 +[16:51:37] <​skullcrasher>​ but also if your mindset with using vertx for this is totally wrong, just let me know
 +
 +[16:53:50] <​skullcrasher>​ temporalfox,​ basically what we miss is something like an isolation rule for * :P
 +
 +[16:54:05] <​skullcrasher>​ so basically just isolate all in the jar file :)
 +
 +[16:55:11] <​temporalfox>​ could you provide a small project that features this behavior ?
 +
 +[16:55:28] <​temporalfox>​ so someone can have a look and see if we can improve your solution
 +
 +[16:55:35] <​temporalfox>​ or do someting in vertx to ease your use case
 +
 +[16:55:38] <​temporalfox>​ that seem valid to me
 +
 +[16:55:49] <​temporalfox>​ a project with 2 deployements for example
 +
 +[16:56:59] <​skullcrasher>​ temporalfox,​ yep I think should be possible. Though may take some time :)
 +
 +[16:57:11] <​temporalfox>​ a small one
 +
 +[16:57:13] <​temporalfox>​ yes it takes some time
 +
 +[16:57:21] <​temporalfox>​ but at least we understand better the problem
 +
 +[16:57:27] <​temporalfox>​ I mean that you are used to your problem
 +
 +[16:57:29] <​temporalfox>​ but not us :-)
 +
 +[16:57:33] <​temporalfox>​ (on yours)
 +
 +[16:57:34] <​skullcrasher>​ Not sure if I get it done today.
 +
 +[16:57:38] <​skullcrasher>​ hehe yes :D
 +
 +[16:58:03] <​skullcrasher>​ But be sure I will write here if I have something on github ;)
 +
 +[16:58:51] <​temporalfox>​ ok
 +
 +[16:59:01] <​skullcrasher>​ temporalfox,​ thx for your patience and help :)
 +
 +[16:59:11] <​temporalfox>​ n/p it's our mission :-)
 +
 +[16:59:22] <​skullcrasher>​ :9
 +
 +[16:59:43] <​skullcrasher>​ we just started using vertx here
 +
 +[17:00:05] <​skullcrasher>​ so expect some more questions in near future :P
 +
 +[17:01:41] <​temporalfox>​ if nobody replies here, you should use the vertx google group
 +
 +[17:01:48] <​temporalfox>​ we are not always available here
 +
 +[17:01:49] <​temporalfox>​ or busy
 +
 +[17:02:45] <​skullcrasher>​ yes of course
 +
 +[17:03:00] <​skullcrasher>​ the last days I'm actively (reading) the google group
 +
 +[17:03:35] <​skullcrasher>​ maybe google group would be much better, it's more persistent and searchable
 +
 +[17:06:31] <​temporalfox>​ it's async
 +
 +[17:06:33] <​temporalfox>​ :)
 +
 +[17:07:04] <​skullcrasher>​ :D
 +
 +[21:03:03] <​amr_>​ i have some newbie questions on vertx2 clustering... im embedding vertx2 into a fat jar
 +
 +[21:03:12] <​amr_>​ i cant seem to find any docs on what i need to do for setting the cluster up, though
 +
 +[21:03:27] <​amr_>​ i guess i need hazelcast... do i run that as a service or can i run that in process?
 +
 +[21:03:32] <​amr_>​ i have many dumb questions :)
 +
 +[21:09:29] <​AlexLehm>​ amr_: hazelcast is running in the jvm process
 +
 +[21:11:02] <​AlexLehm>​ i think you just need to add an option to create the cluster
 +
 +[21:18:14] <​amr_>​ the host and port is the bit im a bit iffy on... host and port of what? how does the other vertx even know about the other one?
 +
 +[21:20:02] <​AlexLehm>​ hazelcast uses multicast I think, if you have just one cluster in your network this will work automatically
 +
 +[21:22:58] <amr> ah, erk
 +
 +[21:23:02] <amr> multicast wont work for me
 +
 +[21:23:31] <amr> i basically just want to forward on some messages on some specific eventbus addresses
 +
 +[21:23:48] <amr> to ther "​other"​ vertxs in a cluster, which could be 0 or 1, i dont care about guarantees or anything
 +
 +[21:26:08] <​AlexLehm>​ i have to admit that i know almost nothing about the cluster
 +
 +[21:26:42] <amr> hehe, same
 +
 +[21:27:01] <amr> which is why im not sure if the clustering is what i need
 +
 +[21:27:09] <amr> maybe i need something homerolled, but that makes me a little sad
 +
 +[21:30:09] <​AlexLehm>​ you could use just a socket probably
 +
 +[21:30:58] <​AlexLehm>​ but you can probably configure hazelcast to use normal udp
 +
 +[21:32:38] <​AlexLehm>​ or tcp
 +
 +[23:22:23] *** ChanServ sets mode: +o temporalfox