Fork me on GitHub
#immutant
<
2015-11-30
>
jcrossley314:11:16

@jaen: immutant.util/at-exit

jcrossley314:11:06

and i don't think you can do (-> resource file) even outside the container if that resource is coming from an archive on the classpath

jaen14:11:07

@jcrossley3: thanks a lot. Yeah, I noticed that later on when tried to make a uberjar, that only file:// protocol works, both vfs:// and jar:// don't, that said jolpin couldn't find migrations when deployed inside Wildfly for some reason. Granted, I might have messed classpaths somehow, I know next to nothing about deploying Java.

jcrossley315:11:56

@jaen: i would expect joplin to be able to find any resources on the classpath whether inside or outside the container

jaen15:11:03

@jcrossley3: So did I, but for some reason when I had $PROJECT_ROOT/db added to resource paths and used migrations/jdbc as the directory (relative to db) outside of container it worked, insider of the container it refused to work and I couldn't figure out why. In the end I patched joplin to work with vfs:// resources, but maybe this isn't the right solution indeed.

jcrossley315:11:34

hmm, i could see vfs being a problem there, actually 😞

jcrossley315:11:12

vfs has been a bit of a bane for us for years

jcrossley315:11:19

still, i wouldn't have expected joplin to care about the resources' protocol, though if it's trying to construct new paths from relative parts, it might.

jaen15:11:17

Yeah, it's kinda vexing you expect to get a File, but VirtualFile is not a File. I'm not sure what the problem exactly was, here's how the lookup code looks in vanilla joplin - https://github.com/juxt/joplin/blob/master/joplin.core/src/joplin/core.clj#L73-L102 - there are three cases (relative file path, folder on classpath, folder inside a jar on classpath) and for some reason inside Wildfly none of the three caught it when I debugged.

jaen15:11:28

Outside of it all was well.

jcrossley315:11:54

that VirtualFile replicates most of File's methods but doesn't extend File reveals a limitation of OOP, IMHO

jcrossley315:11:22

but it's not clear to me from glancing at that code why none of those cases triggered

jaen15:11:49

Yeah, not being able to add to a hierarchy from the outside is a pretty big limitation, I agree. Well, I expected the "search in jars on the classpath" to work but somehow it didn't, maybe I'm just misunderstanding how jars/classpath work, I'll try again later (maybe I missed something obvious), but the VFS workaround is quite enough for now.

jaen17:11:04

@jcrossley3: judging by the feature demo when deploying standalone by uberjar the SSL keystores should work if they are located under resource root, right? I can't seem to get it to work for some reason. Should the files paths be relative to project root or resource root?

jcrossley317:11:04

@jaen: this is without wildfly, right?

jaen17:11:04

@jcrossley3: Yes, this is without Widlfly.

jcrossley317:11:24

the paths for the certs should be relative to the CWD when you invoke the uberjar

jcrossley317:11:20

java -jar target/demo-standalone.jar http2? false

jaen17:11:09

So it's looking relative to where you run Java from

jaen17:11:14

It's not looking inside the jar

jaen17:11:21

Ok, that explaisn a lot.

jcrossley317:11:00

@jaen: you can use absolute paths, too, of course

jcrossley317:11:13

but the feature-demo is using relative ones

jaen17:11:30

Right; I was just somehow confused thinking the lookup differes between out of uberjar and inside it, that is it would look relative to the jar when run from uberjar. Not sure why did I think that. This cleared it up for me.

jcrossley317:11:21

@jaen: if using wildfly, relative paths will be resolved using the working directory from where you started wildfly

jaen17:11:00

Right, that makes sense. That said, aren't those options ignored then anyway and you have to configure the listener in Wildfly?

jcrossley317:11:19

er... yeah. good point. simple_smile

jaen17:11:13

I mean, I'm not sure, I think they should be (like host and :port), but didn't check that its' the case.

jcrossley317:11:54

yeah, all of that ssl/http2 config ultimately resolves to a :configuration builder, which will be ignored within wildfly

jaen17:11:00

Yeah, but what I mean is - maybe, I didn't check - it tries to read keystore files before the configuration builder is ignored, which would result in an exception.

jcrossley317:11:34

yeah, probably

jaen17:11:43

So if that's the case I would have to not specify those explicitly, which I'm doing when deploying to Wildfly just to be sure, but I don't know if it's necessary.

jcrossley318:11:23

i can't decide whether that's a bug or not simple_smile

jcrossley318:11:43

the whole "configuration-is-ignored-when-in-wildfly" thing is troublesome to me. our thinking was that those two user bases would never intersect

jaen18:11:44

I'm mostly intersecting only because I can't decide which makes more sense to me yet

jaen18:11:35

Wildfly is actually pretty enticing in how it just lets you drop the war inside and don't bother with anything else.

jaen18:11:49

Fixed the keystores, works well now, thanks again!