Announcement Announcement Module
Collapse
No announcement yet.
Setting MessageMapper for fileTarget Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Setting MessageMapper for fileTarget

    Hi,

    When using the java configuration for a fileTarget you can set the MessageMapper you want to use (passing it a target dir and a name generator).

    On the other hand when using the xml configuration for the file-target tag, you can only set the target dir and the name generator. Why is this the case? Can't we override the default MessageMapper?

    Thanks in advance,
    Marwan

  • #2
    The default MessageMapper for FileTarget accepts a Message whose payload is one of: File, String, or byte[]. It then just writes the content to the provided directory with the filename as determined by the FileNameGenerator.

    It is questionable that this "mapper" as such should be configurable. In fact, we are already considering whether it's better to just have that same behavior built into the target implementation.

    That said, extension points are definitely necessary. But, it seems that any customization that needs to be done could be handled by a transformer applied to the Message immediately before being processed by the target. I'm afraid that the current approach provides too many ways to accomplish the same thing, and that leads to confusion in general. If the transformer is sufficient (and more intuitive), then we should remove the MessageMapper - or at least no longer treat it as part of the "public" API.

    For the next release, we are working on support for something like the following (exact syntax is subject to change):
    Code:
    <channel-adapter id="fileOut" target="fileTarget">
        <interceptors>
            <transform-on-send transformer="filePayloadTransformer"/>
        </interceptors>
    </channel-adapter>
    
    <file-target id="fileTarget" directory="/tmp/test"/>
    What I am interested in is if this extension point would be sufficient for your use-case. In other words, if you forget that you ever saw the MessageMapper, would this be a logical place to add your behavior?

    Regards,
    Mark

    Comment


    • #3
      Hi Mark,

      Thanks for the fast reply.

      Actually what I want to do is not just blindly copy the payload of the message into the file.
      So I guess your suggestion would do fine in my case. As I understood this is currently available in milestone 5?

      Thanks,
      Marwan

      Comment


      • #4
        Sorry i meant not available in milestone5

        Comment


        • #5
          The channel-adapter with interceptors that I showed is not in M5 but will be available in the next release.

          Can you explain your use case in a bit more detail?

          Comment


          • #6
            In my case, my payload is an object, depending on a certain condition I want to put in the output one thing or another

            I know I can implement a service activator that transforms the payload, but I thought that the mapper (or interceptor) can do the trick.

            What do you think?

            Comment


            • #7
              Do you prefer to create and write the File yourself from your payload Object, or would it be simpler to modify the Object and return one of the supported types (String, File, or byte[])?

              Comment


              • #8
                Now that you asked this, I can see that both of cases are very similar, where I should manipulate the object and return the desired result.
                The difference in the second case is that I have several supported types to pass.

                Comment


                • #9
                  file-source deleteFilesAfterMessageCreation

                  Hi Mark,

                  A different question:
                  To set the file-source to delete the files after retrieving them from the source directory, one has to implement a message creator. This property is just a boolean passed to the constructor of the TextFileMessageCreator for example.
                  Why isn't it provided as an attribute to the file-source in the xml configuration?

                  Thanks,
                  marwan

                  Comment


                  • #10
                    It does seem like that property should be configurable. Could you please raise an issue in JIRA for that?

                    Comment

                    Working...
                    X