This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

file:outbound-channel-adapter : file extension ".writing" issue

Nov 2nd, 2009, 10:31 AM

Hi,

I am using quartz and spring integration to updates the file into local directory using file:outbound-channel-adapter. The file is writing to dir correctly only first time thereafter it is using ".writing" extension to write the file for the one which is already present. My requirement is to update the files and overwrite if present. I am using spring integration version 2.0. Pls. advice me how to overcome this problem.

Comment

Do you have a sample I could try out? Best would be in the form of a JUnit test. I'm not sure if I get your point.

I am in poc mode so I was pushing spring integration so lack junit test case.

Sorry for not being clear with my question earlier ... Let me try to explain my problem again

I have an application which is executed at regular interval to call specific web service and pull some String data. This string data is then written to the local directory using spring integration.

So suppose first time it got file a.xml and b.xml. it is writing to local directory as a.xml and b.xml.

In the second run, it again got a.xml and b.xml file but when S I is trying to write in local directory it writing it as "a.xml.writing" and "b.xml.writing" because a.xml/b.xml is already present in directory.

Comment

I think it might be the case that there are exceptions in your log? If you find those you will be able to track it to the FileWritingMessageHandler which might not be capable of overwriting files? If you manage to do that you could log an issue so we can add a flag to turn this on.

Comment

I would contribute the code, but I think that perhaps a cleaner solution would be to add to FileWritingMessageHandler the following methods ...

Code:

/**
* If true and the file already exists overwrite the original file.
* @param overwrite true or false
*/
public void setOverwriteFiles(final boolean overwrite);
/**
* If set and the file already exists use the filename generator to rename the previous version of the file.
* @param filenameGenerator used to create an alternative filename for the previous version of the file
*/
public void setCollisionFileNameGenerator(final FileNameGenerator filenameGenerator);

Of course it makes no sense to set both overwrite true and a collision filename generator.

Comment

I'm seeing this same issue. All subsequent writes to a file after the first never make it to the destination file. The reason is because the rename from the *.writing file to the destination file is never successful. In my case at least, this seems to be inherent to the Win32FileSystem rename function.

Like the previous poster, I think an option to overwrite the file if it already exists would be a nice edition to FileWritingMessageHandler. INT-1721 captures this issue.

Comment

Thank you very much for you quick response, i tough there were a new parameter to set, but if say it is totally transparent, it's ok for me.
Sorry not to have tested carefully before, i was expecting some overwrite file parameter.
Thanks

Comment

I am using a home made component which is inheriting from an AbstractPollingEndpoint implementing MessageHandler DisposableBean and MessageSource<File>, which have been working with no particular problem for a few years.