[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