Guillaume,
Have I missed the JIRA or isn't there one yet?
Anyway... just to make sure I understand what the problem is:
When the XPath expression accesses the message content to determine the
file name, the XML Source is read and cannot be re-read afterwards,
causing problems when the marshaller tries to write the message to the
disk? Wouldn't it be an option to create a NormalizedMessage Decorator
to provide the re-readability feature and use that one in FileSender's
processInOnly() method?
Regards,
Gert
Guillaume Nodet wrote:
Yeah, this is the same error that has been reported on the
file example from the distribution.
The problem is that the XPath expressions do not ensure
that the XML source can be re-read after use, so it would
be up to the component to ensure that.
Not sure how to handle that in an efficient way ...
Either the components need to make sure the source
can be re-read later (by transforming it to a DOM tree
or StringSource), or we need a more clever interface
on the expression so that the transformation can be done
only if needed.
On 4/4/07, Gert Vanthienen <[EMAIL PROTECTED]> wrote:
L.S.,
Retrieving an XML message from a WebSphere MQ queue and writing it to
disk, using <file:sender/> works fine as long as you don't use any XPath
expressions to determine the file name. I suppose there is some kind of
problem with the XML document not being completely available when the
filename is being determined...? How do I solve this?
It would be even better if there was a way to add the filename property
to the normalized message, to completely avoid having to use marshaler
on the file and FTP endpoints afterwards. What component/service should
I use to accomplish this?
Regards,
Gert Vanthienen
