@lmergen you can avoid using the :parameters declaration for now and just pull out the parameters in (:parameters ctx) and do clojure.spec validation on those manually . clojure.spec support will come in a future release, but probably not until Clojure 1.9 is out of alpha

I wonder whether it makes sense to spec the handler function's ctx

to ensure that those parameters are always there in the form I expect it to be

Doesn't that end up calling the function itself? Unless your response function is pure, that might not be good

oh yeah you're right of course

Hello. Do you now a simple upload example with yada, where I can learn from?

Look at the tests, especially multipart.

I use the edge repo from juxt. When I run it and want to println something in the response function. Nothing is logged in the repl

Use clojure.tools.logging because println requires out thread binding to be set to the REPL.

Arrg. I had to restart boot dev to get the changes of the route working.

A (reset) should be all that is needed.

<- Noob

When you println on a web request thread, the out dynamic var is not set, that's why prontln doesn't work

When I upload a file. I get the multiparts. How do I send the data further to another function?

You create your own PartConsumer

Hang on that's wrong

can you explain what you're trying to do

do you mean you want to process the part's stream yourself (to avoid memory exhaustion with loading it into memory)?

or do you just want to take a part and process it?

the parts are put into the context by the multipart processor, you can fish them out from there in your response function

Have a look at bundles/full/test/yada/multipart_test.clj for examples

I write a little prototype to test how I can upload several image files, which are then send to an s3 storage and also be processed by another function.

If you want to do that, it's possible to write your own PartConsumer which lets you plug-in to the multipart part stream processing and stream to S3, although I'm not sure how this is actually implemented by those who have

if they are image files then you're probably fine to just keep in memory, and in your response function you can fish them out of the context as byte arrays and then copy to S3

what would be the best way for yada to output the exceptions that occur in the response function ?

it seems that the default behaviour is to return an empty body

or is that because of my :produces constraints, which only allow json and edn ?

if you throw exceptions in the response function, yada should render them properly for you (renegotiating the content type along the way) @lmergen - which version of yada are you talking about?

In your upload example, which you deleted at tag 1.20, you wrote a body-stream in the consumer function to a temporary file. I used it, but when I upload a png file, the tmp file isn't viewable anymore.

Is this only usable for octet streams?

when you say it's not viewable anymore, are you saying the file has corrupted? What client are you using to upload?

This png file, becomes this tmp file

I use chrome to upload the file

is the file the same except the suffix?

is there are file size difference?

No. Its different

is the tmp file smaller?

67byte original

259bytes tmp

As I see, the request header has a content-length of 259 bytes.

So maybe its the wrong way I try to solve this.

yes, I see the problem

you are providing your own consumer here -the original example (that I deleted!) was for saving an entire stream

in your case you want yada to process the multipart/form-data body

so don't override the consumer here with :consumer

in this case, use the :response function - it the context you will have byte arrays under :body

print out body and you should see a map of multipart 'names' and the parts

the names are extracted from the Content-Disposition header - if you want to get access to the whole part (to give you full access to the headers - e.g. you'll need the Content-Type of the image to know if it's png or jpeg), then you can use :yada.multipart/parts

this is a bit of 'hidden knowledge' I'm afraid, but it's a fairly recent 'feature'

Is there a middleware in yada, which converts the header into a map? The current header of the multipart is a string

there's some code in Ring that can do it

IIRC

sorry, I'm a bit busy right now

No Problem. Its not that urgent

How is the encoding handled in yada? I can set :charset in :produces. But when I try it in :consumes it doesn't make a difference. I have a filename which has umlauts in it. They are not converted to the right charcode in the response map.

@malcolmsparks i'm running version 1.2.0

but that's strange, i'm seeing empty body responses

what would be the best way to debug this ?

does it have anything to do with running a dev or prod profile ?

@lmergen I was seeing the empty body responses until I upgraded to 1.2.0

hah

Hi All, I am trying to use log4j2 MDC ThreadContext and ThreadContext information set in an interceptor is not getting forwarded to the other interceptors down the chain as yada interceptors are getting executed on separate threads in manifold thread pool. How do we handle this?

@vijayakkineni i think that those things like ThreadContext are inherently incompatible with an async-like execution model which yada uses

i think that the best solution will involve passing around the context explicitly

@lmergen thank you, I am modifying the context and passing it around.