This version (2017/05/27 13:44) is a draft.
Approvals: 0/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