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.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

file name Header missing in the Spring Integration 2.1.3 ?Page Title Module

file name Header missing in the Spring Integration 2.1.3 ?

Hello All,
I have been using Spring Integration 1.0.0 and recently migrated to the latest version which is 2.1.3.
Everything worked out nicely for me except the file name for processed files.

Spring is adding auto generated filename with .msg extensions.

What I would really like to use is the older original file names.

When I went back to debug the old integration code, I found that, once I receive the Message, I could see the file header (spring.integration.file.name) and its value as original filename,
but in the newer version of Spring Integration (2.1.3), I did not see such header being present at all (when intercepted by my transformers).

I searched through and didn't find any relevant problem posted so far.

I found some FilenameGenerator sample implementations which of course worked for me, but I have to generate the new names manually which I really don't want to do.

Any possible solution to this problem? Have anybody encounter this issue so far?

The original file name header is keyed by the constant defined as FileHeaders.ORIGINAL_FILE in 2.x (that literal value is "file_originalFile", but you should try to rely upon the static constant key).

You mentioned that you have Transformers in the flow, so it's possible that you are wiping out request Message headers along the way. If a Transformer returns a full Message object (rather than just a payload), that is treated as a completely new Message. If, on the other hand, a Transformer only deals with the payload and/or headers, it does not replace the original message. This behavior is specific to Transformers (since it's essential to how several Transformer implementations do work). Service Activators, Splitters, and others do not *replace* the original Message even when returning a full Message instance. You could do the copying from the input Message yourself within a Transformer implementation, but usually it's better to work with POJO payloads if possible. Can you describe your Transformer(s) a bit at a high level?

Comment

I don't think I am manually wiping out the header along the way.
My old code (with spring integration 1.0.0) still works fine with the same setup and code. In the newer code, every configuration is just the same except the new jars for integration). I will brief about my flow.

I am reading files in a inbound channel and immediately after that converting it to string using file-to-string-transformer

After that I have a chain of various transformers which performs their own business logic (without actually changing anything in the Message) and finally write the output file with file:outbound-channel-adapter,

However, the first transformer reads the String(provided by file-to-string-transformer) and converts to POJO Mesage using JAXB unmarshaller (by creating a new Message<?>).

And this exact behavior is working in older version of spring integration and I am able to see the output files with the same name as the original.

I will try to create a very simple example which will just read the input file and write back the original file with latest integration jars. Anyway Thanks again and if you can highlight anything which I might be missing, that will be great.

To clarify, what I was describing is the fact that in 2.x, having any Transformer that does return a full Message instance *will* wipe out existing headers (it's treated as an intentional replacement). Is there a reason you need to create a full Message in that Transformer as opposed to just using JAXB to create a POJO payload instance?