Add ability to set a filename generator on a ZipTransformer

[michaelwiles]

Right now when using the zip transformer it is not possible to set the name of the new generated zip file.

Observing the code of doZipTransform:

  protected Object doZipTransform(Message<?> message) {
        Object payload = message.getPayload();
        String baseFileName = this.fileNameGenerator.generateFileName(message);
        String zipEntryName;
        if (message.getHeaders().containsKey("zip_entryFilename")) {
            zipEntryName = (String)message.getHeaders().get("zip_entryFilename");
        } else {
            zipEntryName = baseFileName;
        }

        String zipFileName;
        if (message.getHeaders().containsKey("file_name")) {
            zipFileName = (String)message.getHeaders().get("file_name");
        } else {
            zipFileName = baseFileName + ".zip";
        }

Notice that if a file_name header is not found, then the name from the fileNameGenerator is used and .zip is appended. This behaviour would be great. However, there is a file_name header present (there should be) and that is what the defaultFileNameGenerator uses to generate the file name (and you can't change the filename generator from the default one). So the alternative zipFileName = baseFileName + ".zip"; would never be used if there's a file_name header.

So please can the zip transformers be changed so that the file name generator can be set?

I know I could manually set the file_name to add the zip extension before hand but I'd argue it makes more sense to allow me to set the file name generator to automatically change the file name so that the zip extension is included once the zip transformer has run. If I do this and then remove the zip transformer I will also need to set the file_name back to the one without the zip extension.

[artembilan]

I would say the logic for that if (message.getHeaders().containsKey(FileHeaders.FILENAME)) { is wrong.
The DefaultFileNameGenerator really does the stuff against that header if present.
So, I agree about exposing such an option o an AbstractZipTransformer, however the logic is more complicated than it seems.
Plus pay attention to this in the end:

		return getMessageBuilderFactory()
				.withPayload(zippedData)
				.copyHeaders(message.getHeaders())
				.setHeader(FileHeaders.FILENAME, zipFileName)
				.build();

So, after this transformer that header is indeed overridden to a .zip one.
I still believe that this is a valid behavior.
But for fileNameGenerator option we have provide a fix.

Thanks

[artembilan]

BTW, the spring-integration-zip module in the Extensions project is out of support.
Please, consider to use as latest Spring Integration version as possible.
Not sure that the fix we will provide here would be back-ported to 6.3.x and 6.2.x: might be slight breaking change in behavior.