There is a typo - it’s viritin not firitin in the URL
Oh it’s not 
I have now implemented it as such
UploadFileHandler uploadFileHandler = new UploadFileHandler(
(InputStream inputStream, String fileName, String mimeType)-> {
// Copy to iRODS
copyToIRODS(credentials, inputStream, fileName, mimeType);
logger.info("Upload finished");
});
uploadFileHandler.allowMultiple();
VerticalLayout uploadTab = new VerticalLayout();
uploadTab.add(uploadFileHandler);```
But it still uploads it to the vaadin instance before it starts a stream? What am I missing?For example I try to upload it to a location which I am not allowed to upload it to but it first uploads it to the server and after that the streaming kicks in and notifies the user it is not allowed to upload it… 
I probably need to modify this function
public OutputStream receiveUpload(String s, String s1) {
return UploadFileHandler.this.receiveUpload(s, s1);
}
};```The streaming should work fine (at least with single file upload), checked that today, but with small files & good connection it might appear not as there is buffering by servlet engine and probably with commons-fileupload that Vaadin uses. To me your first code snippet looks just fine.
And yeah, you need to make your credentials handled somehow. I assume that the “not allowed to upload” comes from the copyToIRODS method.
I always test with a 1 gb file to make indeed sure it does not just look like it. Also if I would test and do nothing with the output stream it should in theory stay open till the end of time and vaadin should not continue right. I’ll go back to testing.
so this happens and i added a lot of breakpoints but only is catched the first time in the started listener when it finished the upload widget (not yet upload to the remote resource)
Added some logging to my test and all looks good here:
18:53:54.998077 UploadFileHandler passing the inputStream for developer…
18:53:55.199041 counting… (11729)
18:53:55.400029 counting… (23762)
18:53:55.601016 counting… (33710)
18:53:55.802027 counting… (44925)
18:53:56.003113 counting… (56786)
18:53:56.205028 counting… (65565)
18:53:56.406025 counting… (75495)
18:53:56.608023 counting… (90379)
18:53:56.757354 finishedListener
And started listener gettin hit just before.
Any ideas how I could help to debug? Could you build a reduced test app that has the issue. Could your servlet engine do something odd 
I couldn’t work today, thinking this (and how awful our upload & my hack in Viritin) is 
Here is a draft of rewrite for FileUploadHandler. Probably doesn’t solve your issue, but it is better, because it doesn’t need extra Thread. https://github.com/viritin/flow-viritin/compare/v24...feature/renewed-upload
This particular components gives you a browser file input stream and upload will not happen unless there is a consumer or some sort of code that starts reading from the stream. You should be able to debug the code you write yourself looping through the bytes of input stream and writing them to some other stream like S3 bucket or Database Blob output stream.
secondly I would suggest to implement a smarter component, which launches the transfer in background threads so your UI doesn’t get blocked.
I’ll try to make that somewhat backwards compatible and replace the original version in next release. But need some time with it still.
The FileUploadHandler shouldn’t block the UI. Not the original version nor the current version.
Sorry I wanted to say, background thread means I should be able to navigate around the UI and do some other job, while upload is under process. I know it runs in background but what if I navigate around?
This would kill the upload