Clojurians Log v2

@jaen: immutant.util/at-exit

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

@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.

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

@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.

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

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

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.

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.

Outside of it all was well.

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

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

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.

cool

@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?

@jaen: this is without wildfly, right?

@jcrossley3: Yes, this is without Widlfly.

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

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

Aaaah

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

It's not looking inside the jar

correct

Ok, that explaisn a lot.

:simple_smile:

Thanks!

sure thing!

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

but the feature-demo is using relative ones

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.

cool

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

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

er... yeah. good point. :simple_smile:

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

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

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.

yeah, probably

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.

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

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

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

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

Fixed the keystores, works well now, thanks again!

any time!