See http://issues.apache.org/activemq/browse/SM-902 But the subject is not clearly related to the problem, though they are the same.
About the wrapper, what I did for example in the EIP patterns, which has the same problems, is to write some helpers methods in org.apache.servicemix.jbi.util.MessageUtil. This class has the necessary features to move or copy any existing streams in a JBI exchange. However the problem would be to avoid parsing all the streams if the expressions does not actually need to access the body... On 4/4/07, Gert Vanthienen <[EMAIL PROTECTED]> wrote:
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 >> > > >
-- Cheers, Guillaume Nodet ------------------------ Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
