This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-14
Channels
- # announcements (7)
- # babashka (51)
- # beginners (292)
- # calva (37)
- # chlorine-clover (40)
- # cider (5)
- # clj-kondo (83)
- # cljs-dev (26)
- # cljsrn (36)
- # clojure (172)
- # clojure-argentina (5)
- # clojure-austin (1)
- # clojure-australia (9)
- # clojure-europe (3)
- # clojure-france (7)
- # clojure-gamedev (3)
- # clojure-nl (3)
- # clojure-spec (4)
- # clojure-uk (34)
- # clojurescript (46)
- # community-development (1)
- # conjure (26)
- # core-async (28)
- # data-science (2)
- # datascript (2)
- # datomic (61)
- # devcards (3)
- # emacs (7)
- # events (2)
- # fulcro (65)
- # graalvm (57)
- # instaparse (2)
- # juxt (21)
- # luminus (6)
- # off-topic (21)
- # pathom (1)
- # pedestal (15)
- # reagent (1)
- # shadow-cljs (19)
- # spacemacs (3)
- # specter (1)
- # sql (14)
- # unrepl (4)
- # vscode (1)
- # xtdb (1)
- # yada (4)
Is this channel about clojure.core/juxt
or
, or both π?
Go ahead @jeroenvandijk!
Ok cool π I was wondering about the state of the openId code. Itβs an approach I would like to use
although we'll also try to answer questions about clojure.core/juxt
if you have them π
Ha! Thought so π. Thanks. Edit: Adding a channel topic might help.
I see a lot of open questions in this namespace https://github.com/juxt/apex/blob/master/modules/oauth2/src/juxt/apex/alpha/oauth2/oic.clj Is it still under heavy development / design?
Yes, still under development. In brief, I'm currently working on finishing off https://github.com/juxt/reap because I need it for so many places in Apex, to do the job properly. On the OpenID-Connect front, there's some extra work in checking all the things they need to be asserted before it's ready for a proper security review/audit, but the code does work from a demo perspective, the JWTs are verified properly and it's all mostly there. I'll circle back soon for another go at finishing it along with the other Apex Ring middleware pieces on the roadmap. Hope that helps.
I pinged @malcolmsparks who can answer better than I @jeroenvandijk. Thanks for your Q
Thanks!
I have encountered a 'strange interaction' using the 'capsule' method of creating an upberjar as described in the Edge documentation. The screenshot shows the issue: Following the Edge documentation I cloned Edge to begin, then used 'bin/app' to create two apps, 'my.one' and 'my.two'. Following this I did the following: 1. Left, first show Java version being executed 2. Left, next create 'my.one' uberjar 3. Left, execute 'my.one' uberjar, and make sure it works, which it does 4. Left, kill 'my.one' with CTRL-C 5. Right, first show Java version being executed 6. Right, next create 'my.two' uberjar 7. Right, execute 'my.two' uberjar, and make sure it works, which it does 8. Right, kill 'my.two' with CTRL-C 8. Left, execute 'my.one' uberjar again, and make sure it works, *IT FAILS* 9. Left, execute 'my.one' uberjar again, and send stderr and stdout to files for analysis 10. Left, kill 'my.one' 11. Analyze stdout capture file finding an exception. 12. Left, rebuild 'my.one' 13. Left, execute 'my.one' uberjar, and make sure it works, which it does 14. Right, execute 'my.two' again, and make sure it works, *IT FAILS* 15. Analyze stdout capture file finding an exception. Thoughts?
Reading the capsule docs will help. The application id is used to generate a cache. So I would guess the cache is being overwritten
Around 19:15 I discuss that code @jeroenvandijk
It's under development, but good enough to demo. It's more complete than anything similar I know of.
@malcolmsparks Thank you. Iβll have a look and provide feedback if that is helpful
Yes please!
Reading the capsule docs will help. The application id is used to generate a cache. So I would guess the cache is being overwritten
Yes. The cache was being overwritten. Doing something like this fixed it: ../bin/capsule \ --application-id 'my.one' \ --application-version '1.0.0' \ --main 'edge.main' \ --extra-path 'target/prod' \ -A:prod project.jar It also appears that executing the resulting JAR file something like this: CAPSULE_CACHE_DIR='/tmp' java -jar project.jar will create the cache in /tmp, and delete it automatically after execution. Of course you loose whatever start performance is gained by the cache. Thanks all!