#development
- w
witty-crayon-22786
09/19/2019, 3:30 PM@red-balloon-89377: commented: looks great! - r
red-balloon-89377
09/19/2019, 3:30 PMThanks a lot 🙂 - w
witty-crayon-22786
09/19/2019, 3:30 PMPrior art around how Pants spawns nailgun is that "jvm_opts" vs "args" are just in different fields - w
witty-crayon-22786
09/19/2019, 3:30 PM"just" - w
witty-crayon-22786
09/19/2019, 3:31 PMAnd then things like env vars, etc are not given to the server: only to the client (iirc?) - r
red-balloon-89377
09/19/2019, 3:32 PMI hadn’t noticed the env vars, but it makes total sense 🙂 - w
witty-crayon-22786
09/19/2019, 3:32 PMThat rules out using env vars to spawn nailgun servers, but so far we haven't needed that....? - w
witty-crayon-22786
09/19/2019, 3:32 PMWell, should confirm... I might be full of it - w
witty-crayon-22786
09/19/2019, 3:32 PMActually, that sounds right though, because you can set almost anything using a
for Java-Dsystem=property - r
red-balloon-89377
09/19/2019, 3:34 PMAs far as I know, we take the environment in the
and just write it through the nailgun socket to the request normally, we don’t invalidate the server or anything based on thatNailgunClient - r
red-balloon-89377
09/19/2019, 3:35 PMAnd the server invalidates based on the classpath, the java version, and the jvm_options we pass when starting it up. - w
witty-crayon-22786
09/19/2019, 3:35 PMYep - w
witty-crayon-22786
09/19/2019, 3:37 PMI threw a hail mary and Googled "rust jvm arg parsing crate"... didn't find one, heh. But results are still interesting - w
witty-crayon-22786
09/19/2019, 3:38 PMI think that parsing the relevant ones would not be bad, and would not need to be perfect (could improve over time) - r
red-balloon-89377
09/19/2019, 3:38 PMIf I understand correctly, the biggest risk there is invalidating nailgun too often, right? - w
witty-crayon-22786
09/19/2019, 3:39 PMNo, I don't think so. - r
red-balloon-89377
09/19/2019, 3:39 PMOr, if we don’t filter aggresively enough, not invalidating it when we should, maybe. - w
witty-crayon-22786
09/19/2019, 3:39 PMThe risk is that you either miss some, and the process fails to start because you gave the client a JVM opt - w
witty-crayon-22786
09/19/2019, 3:40 PMOr that you give the server a client arg - w
witty-crayon-22786
09/19/2019, 3:40 PMIn either case, you know quickly - r
red-balloon-89377
09/19/2019, 3:40 PMOh, cool 🙂 That makes me a lot calmer - w
witty-crayon-22786
09/19/2019, 3:41 PMOne other very random idea: would it be odd to support generically "partitioned args" in EPR? - w
witty-crayon-22786
09/19/2019, 3:41 PM@average-vr-56795 ^ - w
witty-crayon-22786
09/19/2019, 3:42 PMargs=[["java", "-cp", "jar.jar"], ["stuff", "for", "the", "client"]] - w
witty-crayon-22786
09/19/2019, 3:43 PMIdea being: "it's a visual separator, except sometimes it's not because we actually look for them to spawn the JVM" - r
red-balloon-89377
09/19/2019, 3:49 PMI think that would make users have to care about which args are which - r
red-balloon-89377
09/19/2019, 3:50 PMAnd at that point I like the “sub-EPR” solution better, as it’s a clearer separation. - w
witty-crayon-22786
09/19/2019, 4:37 PM@red-balloon-89377: the sub-EPR would be a 100% subset - w
witty-crayon-22786
09/19/2019, 4:38 PMie, you'd have to pass all of the JVM args to both - w
witty-crayon-22786
09/19/2019, 4:38 PMi don't think that's better... you'd both need to know which are which, and also duplicate them.