So... it turned out the above actually did work -- I just didn't notice the new window that had opened up with Reveal in it! It has pretty much no styles applied so it's a bit hard to read, and it's light theme instead of dark theme, but it does actually work, so it is sort of bearable to use for debugging a legacy process...
hmm, does slurp
on that string work?
i.e. (println (slurp "cljfxcss:?vlaaad.reveal.style/main#1522973323"))
what does (com.sun.javafx.css.StyleManager/getErrors)
say?
java.io.FileNotFoundException: "cljfxcss:?vlaaad.reveal.style/main#1522973323 (No such file or directory)"
and this produces nil
(<http://clojure.java.io/resource|clojure.java.io/resource> "cljfxcss:?vlaaad.reveal.style/main#1522973323")
and (com.sun.javafx.css.StyleManager/getErrors)
produces nil
It's not a resource, it's url that cljfx/css library instructs jvm to load from the registry...
What's in java.protocol.handler.pkgs
system property after requiring reveal?
"|cljfx.css"
Hmm, looks ok
Does setting it to "cljfx.css"
help?
@vlaaad Can you be more specific about when/where to set that?
I can start the legacy app and connect via a REPL. Should I set that property before or after requiring vlaaad.reveal
? And did you mean "cljfx.css"
or "cljfxcss"
which is what appears to be the protocol on that style loading operation?
@vlaaad I'm beginning to believe that the context in which I'm trying to start Reveal has already called URL/setURLStreamHandlerFactory
which can only be called once per application and which installs a stream handler factory that is "swallowing" the cljfxcss
protocol and throwing an exception instead of returning nil
(which would then cascade down to the java.protocol.handler.pkgs
check).
Hmm, I'm not sure what I can do about this...
Bah. Just confirmed that is not the case. There is no existing stream handler factory in place.
I checked that I can slurp
from a <http://java.net|java.net>.URL
created with an explicit instance of the cljfx.css.cljfxcss.Handler
class. So the class is present and the handler actually does its job.
I suspect it may be a class loader issue that prevents the jfx code (in the Zulu package) from seeing the cljfx.css.cljfxcss.Handler
after the Clojure code is loaded.
I think at this point I'm just out of luck for this particular (legacy) environment. Like I said, it's sort of usable even without the stylesheets loaded... so I can live with it.
I had this in mind:
1. require 'cljfx.css
2. set`java.protocol.handler.pkgs` system property to "cljfx.css"
(without leading |
)
3. require reveal
Gotcha. OK, let me test that.
Nope. Same problem.
actually, you can try just this one-liner to check if it's about protocols:
(slurp (:cljfx.css/url ((requiring-resolve 'cljfx.css/register) ::style {"x" {:x 1}})))
does it return anything to you? I found some zulu jdk (windows), but it didn't have JavaFX built in. Nonetheless, this code doesn't throw for me
There are two different Zulu JDK packagings: a regular one and a version with JFX bundled in.
"cljfxcss:?ws.dev.repl/style#1691341505 (No such file or directory)"
(ws.dev.repl is the ns I was in when I ran that code)
Here's the result of that register
call:
{"x" {:x 1}, :cljfx.css/url "cljfxcss:?ws.dev.repl/style#1691341505"}
okay, I found the JDK with JavaFX
this is what I have:
ws.dev.repl=> (ns ws.dev.repl)
nil
ws.dev.repl=> ((requiring-resolve 'cljfx.css/register) ::style {"x" {:x 1}})
{"x" {:x 1}, :cljfx.css/url "cljfxcss:?ws.dev.repl/style#1691341505"}
ws.dev.repl=> (slurp (:cljfx.css/url ((requiring-resolve 'cljfx.css/register) ::style {"x" {:x 1}})))
"x {\n x: 1;\n}\n"
I can't reproduce your issue, unfortunately
perhaps I need different OS?
maybe there are some additional restrictions on the JVM, like extending url protocols is somehow forbidden?
I launched my with this incantation:
PS C:\Users\Vlaaad\Downloads\zulu8.48.0.53-ca-fx-jdk8.0.265-win_x64\zulu8.48.0.53-ca-fx-jdk8.0.265-win_x64\bin> .\java.exe -cp $(clj -Sdeps "{:deps {cljfx/css {:mvn/version """"1.1.0""""}}}" -Spath) clojure.main
OK. Thanks for trying. The application context I'm working in is somewhat complicated unfortunately.