This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (28)
- # aws (16)
- # beginners (70)
- # boot (54)
- # cider (86)
- # cljsrn (8)
- # clojure (14)
- # clojure-art (12)
- # clojure-conj (2)
- # clojure-hk (45)
- # clojure-nl (2)
- # clojure-poland (2)
- # clojure-russia (32)
- # clojurescript (60)
- # cursive (27)
- # datomic (12)
- # devcards (46)
- # editors (2)
- # emacs (37)
- # immutant (72)
- # jobs (6)
- # ldnclj (7)
- # leiningen (1)
- # off-topic (1)
- # om (205)
- # onyx (16)
- # re-frame (21)
- # reagent (52)
- # slack-help (2)
- # spacemacs (11)
it seems having the alpn-boot jar on the bootclasspath is a fundamental requirement
java -Xbootclasspath/p:/tmp/alpn.jar -jar target/immutant-repro-0.1.0-SNAPSHOT-standalone.jar
that alpn.jar is a copy of [org.mortbay.jetty.alpn/alpn-boot "8.1.5.v20150921"] from my local .m2 repo
@jaen: i just pushed changes to my fork that fix both 'lein run' and invoking core/start! from a REPL. the :prepend true option is critical in that :boot-dependencies vector
still wish i could get the less-awful-ssl stuff working, but i guess like it's name implies, "less awful" is still awful 😉
@jcrossley3: nice, I'll check it out with a while; I made the reproduction with lein for your convenience, but I usually use boot, so I'll have to figure out how to do it there. I assume AOT and genclass something that is required and this won't work without it?
@jaen: no, aot/genclass only required for uberjar creation, which isn't relevant. i only put it in there to make sure all 3 worked (lein run, repl, and uberjar)
that bootclasspath plugin is pretty simple -- it just adds jvm options -- so should be straightforward in boot
I see. When I tried to use
boot-immutantand did it like
(comp (aot) (immutant-war)) I ended up with a war that didn't contain sources and wouldn't boot in Wildfly, so just wanted to know if it's necessary to AOT.
our own @tcrawley is the boot-immutant expert, but i wouldn't think any aot stuff would be required for an immutant-war
jaen: that sounds like it might be a bug. would you mind filing an issue at https://github.com/immutant/boot-immutant/issues
@jcrossley3: so you say
lein run works for your repo when you connect with a browser, yes?
I'm just trying it as-is for now and I get this - https://gist.github.com/jaen/48e4f17644bdaa4bf279
Tried with curl, Open SSL, Chrome 47.0.2526.35 and Firefox 38.0a1 (2015-02-18) and they all just hang there waiting for a reply.
These docs here say it's locked to JDK version http://www.eclipse.org/jetty/documentation/9.2.8.v20150217/alpn-chapter.html
I imagine you have to do it differently if you run from Wildfly instead of standalone, right?
yes, but the principles are the same. this just came out yesterday: http://blog.eisele.net/2015/11/http2-with-jboss-eap-7.html
Yeah, I've just googled this as well - http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html
So I'll just have to figure what XML that maps to and modify the configuration of Wildfly accordingly.
Incidentally, I imagine it's of less interest since you can config that in Wildfly and I guess it's the more "proper" way to deploy than standalone Immutant, but do you know whether you can config cipher suites and TLS levels programmatically for undertow?
maybe? i guess that's what JAAS is for? but probably involves the use of keytool or some openssl tool? i dunno really.
@jaen: i think your changes through the cli will persist in the xml files, so you can copy/paste from them afterwards
I figured that maybe you know of some resource that explains how
<https-listener name="https-2" socket-binding="https-2" security-realm="UndertowRealm" enabled-cipher-suites="ALL:!MD5:!DHA" enabled-protocols="SSLv3, TLSv1.2"/> maps to Undertow config builder, but then maybe again I'm expecting too much documentation ; F
Yeah, it's all fresh stuff so no surprise there's not all that much docs (and in general Java libs documentation seems somewhat lacking at times).