Fork me on GitHub
#juxt
<
2020-04-14
>
jaihindhreddy15:04:52

Is this channel about clojure.core/juxt or , or both πŸ˜›?

jeroenvandijk15:04:28

And is this a good place to ask questions about Apex? πŸ™‚

πŸ‘ 4
jeroenvandijk16:04:36

Ok cool πŸ™‚ I was wondering about the state of the openId code. It’s an approach I would like to use

jonpither16:04:36

Hi @jaihindhreddy this channel for http://juxt.pro

πŸ‘ 4
jarohen16:04:10

although we'll also try to answer questions about clojure.core/juxt if you have them πŸ˜‰

jaihindhreddy18:04:23

Ha! Thought so πŸ˜„. Thanks. Edit: Adding a channel topic might help.

jeroenvandijk16:04:29

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?

malcolmsparks19:04:07

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.

jonpither16:04:37

I pinged @malcolmsparks who can answer better than I @jeroenvandijk. Thanks for your Q

hairfire17:04:49

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?

dominicm19:04:22

Reading the capsule docs will help. The application id is used to generate a cache. So I would guess the cache is being overwritten

πŸ‘ 8
dominicm19:04:08

Given the steps, you probably need to specify an application id

malcolmsparks19:04:52

Around 19:15 I discuss that code @jeroenvandijk

malcolmsparks19:04:38

It's under development, but good enough to demo. It's more complete than anything similar I know of.

jeroenvandijk19:04:32

@malcolmsparks Thank you. I’ll have a look and provide feedback if that is helpful

hairfire21:04:38

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!

πŸ‘ 4