This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (13)
- # announcements (2)
- # avi (1)
- # aws (10)
- # beginners (427)
- # boot (3)
- # cider (4)
- # clara (26)
- # cljs-dev (21)
- # cljsrn (24)
- # clojure (205)
- # clojure-dev (32)
- # clojure-india (26)
- # clojure-japan (1)
- # clojure-russia (256)
- # clojurescript (41)
- # clojurex (1)
- # cursive (38)
- # datavis (99)
- # datomic (15)
- # emacs (19)
- # events (2)
- # funcool (5)
- # immutant (45)
- # ldnclj (3)
- # om (60)
- # omnext (4)
- # onyx (383)
- # overtone (7)
- # parinfer (1)
- # re-frame (3)
- # reagent (7)
- # ring (1)
- # testing (5)
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
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.
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
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.
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.
@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?
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.
@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?
I mean, I'm not sure, I think they should be (like
: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.
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.
the whole "configuration-is-ignored-when-in-wildfly" thing is troublesome to me. our thinking was that those two user bases would never intersect
Wildfly is actually pretty enticing in how it just lets you drop the war inside and don't bother with anything else.