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