java.lang.IllegalArgumentException: wrong number of arguments when calling s3transfer/upload

[p-himik]

(s3t/upload credentials
            :bucket-name bucket-name
            :key key
            :input-stream stream
            :object-metadata {:content-type   content-type
                              :content-length content-length})

results in

Internal Error 
java.lang.IllegalArgumentException: wrong number of arguments
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at amazonica.core$fn_call$fn__45719.invoke(core.clj:875)
	at amazonica.core$intern_function$fn__45759.doInvoke(core.clj:1031)
	at clojure.lang.RestFn.invoke(RestFn.java:703)

I think the issue is that amazonica.core/best-method does not distinguish between methods that accept one bean and methods that accept multiple beans. In this case, it has chosen TransferManager.upload(PutObjectRequest,S3ProgressListener) when it should've chosen TransferManager.upload(PutObjectRequest) instead.

[mcohen01]

workaround is

(require '[amazonica.core :as amz])

(amz/with-credential credentials
  (s3t/upload :bucket-name bucket-name
              :key key
              :input-stream stream
              :object-metadata {:content-type   content-type
                                :content-length content-length}))

[scgilardi]

The workaround doesn't seem sufficient. I'm getting the same error with many attempted permutations of using a map or inline keys and values or using with-credential or not. Sometimes when I get a failure to compile during lein test, I can get a success just by running lein test again immediately. I also sometimes throw in a lein clean with no clear recipe allowing code exactly like the workaround to compile on repeated trials such that it will run (or not) consistently.

[p-himik]

@scgilardi I ended up using positional arguments:

(s3t/upload (get-auth)
            (get-bucket-name bucket-kind) key
            (io/input-stream content) {:content-type   content-type
                                       :content-length (count content)})

[scgilardi]

@p-himik That worked great. Thank you very much!

[scgilardi]

I saw this today in our code and liked the refinement of including commented out keys to get most of the benefit the non-positional calling convention while working around this undesired behavior.

              ;; using positional params for s3transfer/upload to work around:
              ;; https://github.com/mcohen01/amazonica/issues/407
              upload (s3transfer/upload creds
                                        #_:bucket-name container
                                        #_:key name
                                        #_:input-stream input-stream
                                        #_:metadata metadata)