This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-01-04
Channels
- # announcements (42)
- # architecture (18)
- # aws (30)
- # beginners (119)
- # calva (1)
- # cider (3)
- # cljs-dev (15)
- # cljsrn (16)
- # clojure (80)
- # clojure-australia (3)
- # clojure-europe (11)
- # clojure-germany (2)
- # clojure-nl (7)
- # clojure-sanfrancisco (4)
- # clojure-spec (12)
- # clojure-taiwan (2)
- # clojure-uk (10)
- # clojurescript (22)
- # events (2)
- # fulcro (31)
- # ghostwheel (3)
- # jobs (1)
- # kaocha (1)
- # luminus (22)
- # meander (1)
- # off-topic (14)
- # pathom (5)
- # portal (10)
- # re-frame (12)
- # reitit (1)
- # shadow-cljs (19)
- # spacemacs (11)
- # tools-deps (34)
@borkdude is there a way to repro the http-client reflection warning on the JVM? I am happy to fix it but don't see a warning when loading the namespace (from Java 11).
@stuarthalloway After closer inspection, I think the warning came from using import java.lang.reflect.Array;
. This is the warning I got from graalvm:
"Class java.nio.HeapByteBuffer[] is instantiated reflectively but was never registered. Register the class by using org.graalvm.nativeimage.hosted.RuntimeReflection"
from around line 108 in the cognitect.http-client namespace
and this config fixed it for me (using a reflection.json config file):
[
{"name": "[Ljava.nio.HeapByteBuffer;"}
]
So it's no longer a problem for me and probably not something that can be fixed without avoiding reflect.Array
, which is used by into-array
(although it's the first time I encountered this specific problem with into-array
). Thanks for looking into it and sorry for taking up your time.@borkdude Thanks for all you are doing exploring that is possible with GraalVM. I don't use it for day job stuff (yet?), but if there is low hanging fruit happy to help grab it.
Good to hear. For context, we are working on a babashka aws pod (which wraps aws-api), which runs natively, so you can use aws-api in scripts without a JVM with very fast startup time.
Babashka pods are basically CLIs but they expose their data through EDN or Transit (or JSON) and can be called using normal functions instead of shelling out, RPC-style.
that sounds terrific
This is a list of existing pods that can already be used from babashka: https://github.com/babashka/pod-registry A few of them are written in Clojure and compiled with GraalVM native-image.
we have a working prototype, but there is some stuff around aws-api returning an inputstream for resources from s3 (and possibly others) which we have to translate into bytes, because it has to go over the wire via transit
Any idea how to pass x-aws-acl
header in the PutObject
when using cognitect-labs/aws-api? - I tried overriding the default multimethod for modify-http-request
but no luck so far. It's relevant when uploading files so s3 and making them publicly accessible in one request
You can (should?) use :PutObjectAcl
for this instead of messing with headers.
I see you want to do it in one request, but thatâs not how itâs designed.
@U0JEFEZH6 itâs x-amz-acl
, not x-aws-acl
. Did your attempt with modify-http-request
use the right header name?
> is the ACL not available on PutObject? No, @U050ECB92, it is not not available on PutObject.
FYI :ACL
is also available on :CreateBucket
Apparently, my joke about ânot notâ was missed by at least one reader, so to clarify âŚ. :ACL
is absolutely, definitely, 100% a supported key on :PutObject
Got that @U0JEFEZH6?
I'll double check in ~45m, AFK right now. But thanks for the pointers - I'm fairy sure there were no typos, but I'll verify everything :thumbsup:
OK. Iâd recommend you donât worry about the header and just use the :ACL
key in the :request
map. Let us know how it goes!
@U0ENYLGTA that works, thank you! Next time, I'll check aws.client.api/doc
Glad that worked out.