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




--
Cheers,
Guillaume Nodet
------------------------
Architect, LogicBlaze (http://www.logicblaze.com/)
Blog: http://gnodet.blogspot.com/

Reply via email to