Announcement Announcement Module
No announcement yet.
file:outbound-channel-adapter : file extension ".writing" issue Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

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


    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.

    Thanks in Advance


  • #2
    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.


    • #3
      Originally posted by iwein View Post
      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.

      some code snippet (in case i am doing something wrong)


      <bean id="fileBasedHandler" class= .......
      <si:channel id="inputMessage"/>
      <si:channel id="outputFile"/>
      <file:outbound-channel-adapter channel="outputFile" directory="${}" auto-create-directory="true" filename-generator="fileBasedHandler" />

      public class FileBasedHandler extends DefaultFileNameGenerator{

      public FileBasedHandler(){

      //sending message as
      MessageChannel input = (MessageChannel)appContext.getBean("outputFile");
      msg=MessageBuilder.withPayload(strRule).setHeader( "MSG_FILENAME", currentRuleName).build();
      boolean sendStatus = input.send(msg);

      Appreciate you help




      • #4
        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.

        I'm just guessing... without log messages / stacktraces / testcases you may assume I'm wrong.


        • #5
          I encountered something similar (Spring-integration 1.0.3) and needed to make sure that I could over-write multiple versions of a file.

          I created a file renaming endpoint that checked for the existence of the file and, if found, renamed the previous version before passing the message on to the < file : outbound-channel-adapter/>



          • #6
            That sounds like a useful feature.


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

                   * 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.


              • #8
                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.


                • #9
                  Hi all,
                  I cannot find anywhere in the last release 2.0.5 any option like this, does it exist ?
                  The INT-1721 says it has been solved.

                  Can you please help ? before i code it myself

                  thank you very much


                  • #10
                    Are you saying that it doesn't work for you. I mean right now it should override an existing file.


                    • #11
                      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.


                      • #12
                        well it doesn't seem to work for me:

                        after writing file with the same name, i still have two files (one with .writing extension, and the old one)
                        I have no error in log file.
                        Can you help ?

                        Attached Files


                        • #13
                          Can you describe your environment and share your config so we can try to reproduce it?


                          • #14

                            - windows 7 Pro SP1
                            - all spring integration components updated to 2.0.5

                            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.

                            Here is how i initialize the writer part:

                            if (outputDirectory != null) {
                            relativePath = conf.getString(getName() + ".output.relative.path","");
                            filenamePattern = conf.getString(getName() + ".output.filename.pattern","");

                            ouputFile = new File(outputDirectory + "/" +;
                            if (!ouputFile.exists()) {
                            logger.debug("Creating directory " + ouputFile);
                            (new File(ouputFile.getPath())).mkdirs();
                            } else if (!ouputFile.canWrite()) {
                            logger.debug("Trying to set directory readable " + ouputFile);
                            (new File(ouputFile.getPath())).setWritable(true);
                            writer = new FileWritingMessageHandler(ouputFile.getAbsoluteFil e());

                            writer.setChannelResolver(ApplicationContextProvid er.getChannelRegistry());
                            writer.setBeanFactory(ApplicationContextProvider.g etApplicationContext());

                            String channel = BeansNormalizedNames.getCoreRouterInputChannel();
                            writer.setOutputChannel((MessageChannel) ApplicationContextProvider.getChannelRegistry().ge tChannel(channel));

                  "writing in " + ouputFile.getAbsolutePath());
                            And the corresponding configuration file:

                            USER_PLATE_XML_FILE_WRITER.type = FILE
                            USER_PLATE_XML_FILE_WRITER.trigger = 10000
                            USER_PLATE_XML_FILE_WRITER.messages.per.poll = 10
                   = C:/Users/max/Documents/AndromasTest/plates
                            USER_PLATE_XML_FILE_WRITER.output.relative.path = yyyy/MM/dd
                            Just tell me if this is not clear...


                            • #15
                              Why are you not using <int-file:outbound-channel-adapter>? I mean why do you need custom component?