Hi, OK, now I see what I overlooked, the coding is also called by the delete operation before the rename operation. That should really not issue a warning. I will think about something.
I created issue https://issues.apache.org/jira/browse/CAMEL-10841 for it. Best regards Stephan -----Original Message----- From: Siano, Stephan [mailto:[email protected]] Sent: Donnerstag, 16. Februar 2017 08:42 To: [email protected] Subject: RE: StfpOperations 1.18.2 - a log is very annoying Hi, I am actually the guy who added the log, because without it, it is nearly impossible to find out why a file was not removed in case it was not removed (e.g. because the server had already closed the connection). What is a valid case to configure a consumer to remove the file and find it already removed? I would still prefer to keep the log statement somehow, but if there are valid cases for it, it would make sense to reduce the severity of the log (e.g. to info or even debug). Best regards Stephan -----Original Message----- From: g-lundy [mailto:[email protected]] Sent: Mittwoch, 15. Februar 2017 14:06 To: [email protected] Subject: StfpOperations 1.18.2 - a log is very annoying Hi, Camel version : 1.18 I'm using an enpoint like this one : - sftp://myserver/folder1/folder2?idempotent=true&stepwise=false&...&move=../archive With 1.18.2, I have logs like this : (I don't have these logs with 1.18.1) Looking for code of GenericFileProcessStrategySupport (1.18.2) : ==> looks good Looking for code of SftpOperations.deleteFile ==> the log is present in the catch(...) it has been added in 1.18.2 on 2017/01/17 see https://github.com/apache/camel/commit/dff9f28cd23773d68843354e9bdd0a63d373f8fd#diff-160fb29058daf7d0c2f52428b5186da6 is it possible todo something to avoid the log of this exception for this valid behavior ? Regard. guillaume -- View this message in context: http://camel.465427.n5.nabble.com/StfpOperations-1-18-2-a-log-is-very-annoying-tp5793923.html Sent from the Camel - Users mailing list archive at Nabble.com.
