Setting MessageMapper for fileTarget

[marwan simaan]

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

[Mark Fisher]

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):

<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

[marwan simaan]

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

[marwan simaan]

Sorry i meant not available in milestone5

[Mark Fisher]

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?

[marwan simaan]

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?

[Mark Fisher]

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[])?

[marwan simaan]

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.

[marwan simaan]

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

[Mark Fisher]

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