File Serilizer running to early

> Hi all,
>
>             I have an XPL which takes a data input and a config input,
> the data is XML to be saved to a file and the config gives the
> directory and filename. The XPL encodes the XML and saves it to a
> file. This is fed to by another XPL. The second XPL uses XSLT to
> transform the raw XML into the format with which I wish to save it.
> The problem is that the file-serializer isn’t waiting for the XSLT to
> take place and keeps removing all the data from the file.
>
> I personally see this as a bug, because the processor should wait
> until the input is formed. Is there a best practice to get around
> this? Has anyone else run into this problem?

>-----Original Message-----
>From: Colin O'Brien [mailto:[hidden email]]
>Sent: 18 January 2006 17:25
>To: [hidden email]
>Subject: Re: [ops-users] File Serilizer running to early
>
>Hi Ryan,
>
>just a thought - a downstream pipeline will only cause an upstream
>processor to run if it needs it to be run. Perhaps it is thinking that
>the output is unchanged and/or is empty - possibly due to you running
>it once and producing nothing, and now the caching is thinking that
>nothing has changed even though you think it has?
>
>Colin
>
>On Jan 18, 2006, at 12:13 PM, Ryan Puddephatt wrote:
>
>> Hi all,
>>
>>             I have an XPL which takes a data input and a config input,
>> the data is XML to be saved to a file and the config gives the
>> directory and filename. The XPL encodes the XML and saves it to a
>> file. This is fed to by another XPL. The second XPL uses XSLT to
>> transform the raw XML into the format with which I wish to save it.
>> The problem is that the file-serializer isn’t waiting for the XSLT to
>> take place and keeps removing all the data from the file.
>>
>> I personally see this as a bug, because the processor should wait
>> until the input is formed. Is there a best practice to get around
>> this? Has anyone else run into this problem?
>

> Stephen,
>
>             I placed debugs in, but only one runs, this is the XSLT
> processor that builds the config for the file-serializer. I then get the
> exception below, and there is now nothing in the XML file
>
>  
>
> org.orbeon.oxf.common.ValidationException: null, line -1, column -1:
> Fatal error: Premature end of file.
>
> null, line -1, column -1: Fatal error: Premature end of file.
>
>       at
> org.orbeon.oxf.xml.XMLUtils$ErrorHandler.fatalError(XMLUtils.java:209)
>
>       at
> orbeon.apache.xerces.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:218)
>
>       at
> orbeon.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384)
>
>       at
> orbeon.apache.xerces.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:314)
>
>       at
> orbeon.apache.xerces.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:230)
>
>       at
> orbeon.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:792)
>
>       at
> orbeon.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:758)
>
>       at orbeon.apache.xerces.parsers.XMLParser.parse(XMLParser.java:148)
>
>       at
> orbeon.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1178)
>
>       at org.orbeon.oxf.xml.XMLUtils.inputSourceToSAX(XMLUtils.java:253)
>
>       at org.orbeon.oxf.xml.XMLUtils.inputStreamToSAX(XMLUtils.java:238)
>
>       at
> org.orbeon.oxf.resources.ResourceManagerBase.getContentAsSAX(ResourceManagerBase.java:134)
>
>       at
> org.orbeon.oxf.resources.PriorityResourceManagerImpl$4.run(PriorityResourceManagerImpl.java:106)
>
>       at
> org.orbeon.oxf.resources.PriorityResourceManagerImpl.delegate(PriorityResourceManagerImpl.java:252)
>
>       at
> org.orbeon.oxf.resources.PriorityResourceManagerImpl.getContentAsSAX(PriorityResourceManagerImpl.java:104)
>
>       at
> org.orbeon.oxf.processor.generator.URLGenerator$OXFResourceHandler.readXML(URLGenerator.java:636)
>
>       at
> org.orbeon.oxf.processor.generator.URLGenerator$1.readImpl(URLGenerator.java:404)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:354)
>
>       at
> org.orbeon.oxf.processor.transformer.xslt.XSLTTransformer.access$600(XSLTTransformer.java:60)
>
>       at
> org.orbeon.oxf.processor.transformer.xslt.XSLTTransformer$1.readImpl(XSLTTransformer.java:193)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl$ConcreteProcessorFilter$ForwarderProcessorOutput.read(ProcessorImpl.java:941)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:354)
>
>       at
> org.orbeon.oxf.processor.DebugProcessor$1.readImpl(DebugProcessor.java:62)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl$ConcreteProcessorFilter.read(ProcessorImpl.java:965)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.pipeline.TeeProcessor.access$100(TeeProcessor.java:36)
>
>       at
> org.orbeon.oxf.processor.pipeline.TeeProcessor$1.readImpl(TeeProcessor.java:57)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor.access$1500(PipelineProcessor.java:66)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor$6.run(PipelineProcessor.java:572)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.executeParents(ProcessorImpl.java:533)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor.access$1600(PipelineProcessor.java:66)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor$InternalTopOutput.readImpl(PipelineProcessor.java:568)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.serializer.legacy.XMLSerializer.readInput(XMLSerializer.java:58)
>
>       at
> org.orbeon.oxf.processor.serializer.HttpTextSerializer$1.readImpl(HttpTextSerializer.java:101)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl$ConcreteProcessorFilter$ForwarderProcessorOutput.read(ProcessorImpl.java:941)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:354)
>
>       at
> org.orbeon.oxf.processor.DebugProcessor$1.readImpl(DebugProcessor.java:62)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl$ConcreteProcessorFilter.read(ProcessorImpl.java:965)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.serializer.FileSerializer.access$900(FileSerializer.java:34)
>
>       at
> org.orbeon.oxf.processor.serializer.FileSerializer$3.read(FileSerializer.java:219)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readCacheInputAsObject(ProcessorImpl.java:470)
>
>       at
> org.orbeon.oxf.processor.serializer.FileSerializer.start(FileSerializer.java:211)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor$11.run(PipelineProcessor.java:652)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.executeChildren(ProcessorImpl.java:515)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor.start(PipelineProcessor.java:649)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor$11.run(PipelineProcessor.java:652)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.executeChildren(ProcessorImpl.java:515)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor.start(PipelineProcessor.java:649)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor$1.getInput(PipelineProcessor.java:140)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor$1.readImpl(PipelineProcessor.java:89)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:354)
>
>       at
> org.orbeon.oxf.processor.IdentityProcessor$1.readImpl(IdentityProcessor.java:33)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor.access$000(PipelineProcessor.java:66)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor$2.run(PipelineProcessor.java:96)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.executeChildren(ProcessorImpl.java:515)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor.access$100(PipelineProcessor.java:66)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor$1.readImpl(PipelineProcessor.java:94)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.pipeline.choose.ConcreteChooseProcessor$1.readImpl(ConcreteChooseProcessor.java:122)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:354)
>
>       at
> org.orbeon.oxf.processor.IdentityProcessor$1.readImpl(IdentityProcessor.java:33)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor.access$000(PipelineProcessor.java:66)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor$2.run(PipelineProcessor.java:96)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.executeChildren(ProcessorImpl.java:515)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor.access$100(PipelineProcessor.java:66)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor$1.readImpl(PipelineProcessor.java:94)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:354)
>
>       at
> org.orbeon.oxf.processor.IdentityProcessor$1.readImpl(IdentityProcessor.java:33)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor.access$000(PipelineProcessor.java:66)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor$2.run(PipelineProcessor.java:96)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.executeChildren(ProcessorImpl.java:515)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor.access$100(PipelineProcessor.java:66)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor$1.readImpl(PipelineProcessor.java:94)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.pipeline.choose.ConcreteChooseProcessor$1.readImpl(ConcreteChooseProcessor.java:122)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:354)
>
>       at
> org.orbeon.oxf.processor.IdentityProcessor$1.readImpl(IdentityProcessor.java:33)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor.access$000(PipelineProcessor.java:66)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor$2.run(PipelineProcessor.java:96)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.executeChildren(ProcessorImpl.java:515)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor.access$100(PipelineProcessor.java:66)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor$1.readImpl(PipelineProcessor.java:94)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.pipeline.choose.ConcreteChooseProcessor$1.readImpl(ConcreteChooseProcessor.java:122)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.pipeline.TeeProcessor.access$100(TeeProcessor.java:36)
>
>       at
> org.orbeon.oxf.processor.pipeline.TeeProcessor$1.readImpl(TeeProcessor.java:57)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$6.read(ProcessorImpl.java:987)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$ProcessorOutputImpl.read(ProcessorImpl.java:1170)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsSAX(ProcessorImpl.java:349)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readInputAsDOM4J(ProcessorImpl.java:404)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl$4.read(ProcessorImpl.java:428)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readCacheInputAsObject(ProcessorImpl.java:470)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.readCacheInputAsDOM4J(ProcessorImpl.java:426)
>
>       at
> org.orbeon.oxf.processor.pipeline.choose.ConcreteChooseProcessor.start(ConcreteChooseProcessor.java:185)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor$11.run(PipelineProcessor.java:652)
>
>       at
> org.orbeon.oxf.processor.ProcessorImpl.executeChildren(ProcessorImpl.java:515)
>
>       at
> org.orbeon.oxf.processor.pipeline.PipelineProcessor.start(PipelineProcessor.java:649)
>
>       at
> org.orbeon.oxf.processor.PageFlowControllerProcessor.start(PageFlowControllerProcessor.java:416)
>
>       at org.orbeon.oxf.pipeline.InitUtils.runProcessor(InitUtils.java:86)
>
>       at
> org.orbeon.oxf.webapp.ProcessorService.service(ProcessorService.java:95)
>
>       at
> org.orbeon.oxf.servlet.OPSServletDelegate.service(OPSServletDelegate.java:144)
>
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>
>       at org.orbeon.oxf.servlet.OPSServlet.service(OPSServlet.java:74)
>
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>
>       at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
>
>       at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
>
>       at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
>
>       at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
>
>       at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>
>       at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>
>       at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>
>       at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
>
>       at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>
>       at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>
>       at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2422)
>
>       at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
>
>       at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
>
>       at
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
>
>       at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
>
>       at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:163)
>
>       at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
>
>       at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>
>       at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>
>       at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
>
>       at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
>
>       at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
>
>       at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>
>       at
> org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:199)
>
>       at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
>
>       at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:700)
>
>       at
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:584)
>
>       at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
>
>       at java.lang.Thread.run(Thread.java:595)
>
>  
>
>  
>
> *Ryan Puddephatt*
>
> Web Developer
>
> TFX Group
>
> 1 Michaelson Square
>
> Livingston
>
> West Lothian
>
> Scotand
>
> EH54 7DP
>
>  
>
> * [hidden email]
>
> ( 01506 407 110
>
> 7  01506 407 108
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Stephen Bayliss [mailto:[hidden email]]
> *Sent:* 18 January 2006 17:23
> *To:* [hidden email]
> *Subject:* RE: [ops-users] File Serilizer running to early
>
>  
>
> Can you see from the OPS monitoring when each input is being read?  
> Maybe add debug attributes to all the inputs and outputs so you can see
> what’s happening when.
>
>  
>
> My suspicion would be that something somewhere is not connected, so that
> OPS isn’t identifying that one XPL is dependent on the other.  I’ve had
> similar things which have turned out to be daft mistakes that I’ve made,
> like supplying the wrong href on an input for example…
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Ryan Puddephatt [mailto:[hidden email]]
> *Sent:* 18 January 2006 17:13
> *To:* [hidden email]
> *Subject:* [ops-users] File Serilizer running to early
>
>  
>
> Hi all,
>
>             I have an XPL which takes a data input and a config input,
> the data is XML to be saved to a file and the config gives the directory
> and filename. The XPL encodes the XML and saves it to a file. This is
> fed to by another XPL. The second XPL uses XSLT to transform the raw XML
> into the format with which I wish to save it. The problem is that the
> file-serializer isn’t waiting for the XSLT to take place and keeps
> removing all the data from the file.
>
>  
>
> I personally see this as a bug, because the processor should wait until
> the input is formed. Is there a best practice to get around this? Has
> anyone else run into this problem?
>
>  
>
> Thanks
>
>  
>
> R.
>
>  
>
> *Ryan Puddephatt*
>
> Web Developer
>
> TFX Group
>
> 1 Michaelson Square
>
> Livingston
>
> West Lothian
>
> Scotand
>
> EH54 7DP
>
>  
>
> * [hidden email]
>
> ( 01506 407 110
>
> 7  01506 407 108
>
>  
>
>  
>
>
> ------------------------------------------------------------------------
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

> Hi all,
>
>             I have an XPL which takes a data input and a config input,
> the data is XML to be saved to a file and the config gives the directory
> and filename. The XPL encodes the XML and saves it to a file. This is
> fed to by another XPL. The second XPL uses XSLT to transform the raw XML
> into the format with which I wish to save it. The problem is that the
> file-serializer isn’t waiting for the XSLT to take place and keeps
> removing all the data from the file.
>
>  
>
> I personally see this as a bug, because the processor should wait until
> the input is formed. Is there a best practice to get around this? Has
> anyone else run into this problem?
>
>  
>
> Thanks
>
>  
>
> R.
>
>  
>
> *Ryan Puddephatt*
>
> Web Developer
>
> TFX Group
>
> 1 Michaelson Square
>
> Livingston
>
> West Lothian
>
> Scotand
>
> EH54 7DP
>
>  
>
> * [hidden email]
>
> ( 01506 407 110
>
> 7  01506 407 108

> Colin,
> I have run a debug on the XSLT processor transforming the data to be
> saved, and it always produces a result. It basically opens the XML
> file,
> changes the two elements then saves it back. I guess this could cause
> the
> file-serializer to think nothing is changing. Any ideas on how to get
> round
> this?
>
> Ryan Puddephatt
> Web Developer
> TFX Group
> 1 Michaelson Square
> Livingston
> West Lothian
> Scotand
> EH54 7DP
>
> * [hidden email]
> ( 01506 407 110
> 7  01506 407 108
>
>
>> -----Original Message-----
>> From: Colin O'Brien [mailto:[hidden email]]
>> Sent: 18 January 2006 17:25
>> To: [hidden email]
>> Subject: Re: [ops-users] File Serilizer running to early
>>
>> Hi Ryan,
>>
>> just a thought - a downstream pipeline will only cause an upstream
>> processor to run if it needs it to be run. Perhaps it is thinking that
>> the output is unchanged and/or is empty - possibly due to you running
>> it once and producing nothing, and now the caching is thinking that
>> nothing has changed even though you think it has?
>>
>> Colin
>>
>> On Jan 18, 2006, at 12:13 PM, Ryan Puddephatt wrote:
>>
>>> Hi all,
>>>
>>>             I have an XPL which takes a data input and a config
>>> input,
>>> the data is XML to be saved to a file and the config gives the
>>> directory and filename. The XPL encodes the XML and saves it to a
>>> file. This is fed to by another XPL. The second XPL uses XSLT to
>>> transform the raw XML into the format with which I wish to save it.
>>> The problem is that the file-serializer isn’t waiting for the XSLT to
>>> take place and keeps removing all the data from the file.
>>>
>>> I personally see this as a bug, because the processor should wait
>>> until the input is formed. Is there a best practice to get around
>>> this? Has anyone else run into this problem?
>>
>
>
>
>
> --
> You receive this message as a subscriber of the
> [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

>-----Original Message-----
>From: Colin O'Brien [mailto:[hidden email]]
>Sent: 18 January 2006 19:28
>To: [hidden email]
>Subject: Re: [ops-users] File Serilizer running to early
>
>Hi Ryan
>
>well, when I get to the point where I am convinced this is the only
>explanation for what I am seeing, I simply close everything down -
>apache and tomcat in my case - and start them up again - sometimes it
>even makes a difference ;-)
>This would seem to only be relevant for you though, if as I said, you
>had at one time indeed incorrectly created an empty input to your file
>serializer (otherwise I would be concerned that at some point in the
>future a working transformation might produce a repeat result and you
>again find an empty file instead of repeat/cached data)
>
>Colin
>
>On Jan 18, 2006, at 12:31 PM, Ryan Puddephatt wrote:
>
>> Colin,
>> I have run a debug on the XSLT processor transforming the data to be
>> saved, and it always produces a result. It basically opens the XML
>> file,
>> changes the two elements then saves it back. I guess this could cause
>> the
>> file-serializer to think nothing is changing. Any ideas on how to get
>> round
>> this?
>>
>> Ryan Puddephatt
>> Web Developer
>> TFX Group
>> 1 Michaelson Square
>> Livingston
>> West Lothian
>> Scotand
>> EH54 7DP
>>
>> * [hidden email]
>> ( 01506 407 110
>> 7  01506 407 108
>>
>>
>>> -----Original Message-----
>>> From: Colin O'Brien [mailto:[hidden email]]
>>> Sent: 18 January 2006 17:25
>>> To: [hidden email]
>>> Subject: Re: [ops-users] File Serilizer running to early
>>>
>>> Hi Ryan,
>>>
>>> just a thought - a downstream pipeline will only cause an upstream
>>> processor to run if it needs it to be run. Perhaps it is thinking that
>>> the output is unchanged and/or is empty - possibly due to you running
>>> it once and producing nothing, and now the caching is thinking that
>>> nothing has changed even though you think it has?
>>>
>>> Colin
>>>
>>> On Jan 18, 2006, at 12:13 PM, Ryan Puddephatt wrote:
>>>
>>>> Hi all,
>>>>
>>>>             I have an XPL which takes a data input and a config
>>>> input,
>>>> the data is XML to be saved to a file and the config gives the
>>>> directory and filename. The XPL encodes the XML and saves it to a
>>>> file. This is fed to by another XPL. The second XPL uses XSLT to
>>>> transform the raw XML into the format with which I wish to save it.
>>>> The problem is that the file-serializer isn’t waiting for the XSLT to
>>>> take place and keeps removing all the data from the file.
>>>>
>>>> I personally see this as a bug, because the processor should wait
>>>> until the input is formed. Is there a best practice to get around
>>>> this? Has anyone else run into this problem?
>>>
>>
>>
>>
>>
>> --
>> You receive this message as a subscriber of the
>> [hidden email] mailing list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>

>-----Original Message-----
>From: Colin O'Brien [mailto:[hidden email]]
>Sent: 18 January 2006 19:28
>To: [hidden email]
>Subject: Re: [ops-users] File Serilizer running to early
>
>Hi Ryan
>
>well, when I get to the point where I am convinced this is the only
>explanation for what I am seeing, I simply close everything down -
>apache and tomcat in my case - and start them up again - sometimes it
>even makes a difference ;-)
>This would seem to only be relevant for you though, if as I said, you
>had at one time indeed incorrectly created an empty input to your file
>serializer (otherwise I would be concerned that at some point in the
>future a working transformation might produce a repeat result and you
>again find an empty file instead of repeat/cached data)
>
>Colin
>
>On Jan 18, 2006, at 12:31 PM, Ryan Puddephatt wrote:
>
>> Colin,
>> I have run a debug on the XSLT processor transforming the data to be
>> saved, and it always produces a result. It basically opens the XML
>> file,
>> changes the two elements then saves it back. I guess this could cause
>> the
>> file-serializer to think nothing is changing. Any ideas on how to get
>> round
>> this?
>>
>> Ryan Puddephatt
>> Web Developer
>> TFX Group
>> 1 Michaelson Square
>> Livingston
>> West Lothian
>> Scotand
>> EH54 7DP
>>
>> * [hidden email]
>> ( 01506 407 110
>> 7  01506 407 108
>>
>>
>>> -----Original Message-----
>>> From: Colin O'Brien [mailto:[hidden email]]
>>> Sent: 18 January 2006 17:25
>>> To: [hidden email]
>>> Subject: Re: [ops-users] File Serilizer running to early
>>>
>>> Hi Ryan,
>>>
>>> just a thought - a downstream pipeline will only cause an upstream
>>> processor to run if it needs it to be run. Perhaps it is thinking that
>>> the output is unchanged and/or is empty - possibly due to you running
>>> it once and producing nothing, and now the caching is thinking that
>>> nothing has changed even though you think it has?
>>>
>>> Colin
>>>
>>> On Jan 18, 2006, at 12:13 PM, Ryan Puddephatt wrote:
>>>
>>>> Hi all,
>>>>
>>>>             I have an XPL which takes a data input and a config
>>>> input,
>>>> the data is XML to be saved to a file and the config gives the
>>>> directory and filename. The XPL encodes the XML and saves it to a
>>>> file. This is fed to by another XPL. The second XPL uses XSLT to
>>>> transform the raw XML into the format with which I wish to save it.
>>>> The problem is that the file-serializer isn't waiting for the XSLT to
>>>> take place and keeps removing all the data from the file.
>>>>
>>>> I personally see this as a bug, because the processor should wait
>>>> until the input is formed. Is there a best practice to get around
>>>> this? Has anyone else run into this problem?
>>>
>>
>>
>>
>>
>> --
>> You receive this message as a subscriber of the
>> [hidden email] mailing list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>