Community
Participate
Working Groups
Error description: When ONFILECLOSE property is used with EXPAND statement, then xpand creates multiple output buffers which get populated with generated data. After FileHandle with multiple buffers supplied to a PostProcessor the getBuffer() method returns current buffer's content instead of whole content. This breaks all available PostProcessor as they expect whole buffer to be returned. In my particular case JavaBeautifier does not work. Ho to reproduce: 1. Create a .xpt file generating some file. 2. Make sure there is at least one EXPAND statement with ONFILECLOSE property. 3. Add a PostProcessor which prints FileHandle.getBuffer() to system output 4. Run the generator and compare system output to the generated file. System output will contain a part of generated file. What should be fixed: FileHandle.getBuffer() must return whole buffer when called from within a PostProcessor as this was the contract before ONFILECLOSE property was introduced. Thanks & best regards, Sergej
To fulfil the original contract and avoid API breaks the following has been implemented in FileHandleImpl: On deactivation of an insertion point the entry in the namedBuffers map for the given Statement will be removed. Thus after all insertion points were used the map will be empty. getBuffer() will now check whether the map is empty. In the non-empty case there are still insertion points about to be used, which will be the case during Xpand evaluation. After all templates have been processed the map will be empty. If there are no insertion points left or none used at all, the buffers list gets compacted to one, which will be the complete buffer. As a result, getBuffer() will return the whole buffer again. Added unit test FileHandleImplTest to test this behavior. Pushed changed to master.
The final build for SR2 was today, so this will only make it into the indigo release. I've reset the target milestone and release train flags.
Well actually it is tomorrow. But it is RC4 (should be quite). I don't think we should have such late changes. Is it critical?
For someone who uses ONFILECLOSE with Postprocessors it is important. Normal case is further w/o usage of ONFILECLOSE, and this behavior should be unchanged. I have assured this by a unit test.
We do not plan to have an SR2 build for Xpand and I don't think that this bug is worthy to have one considering the effort for branching, backporting, creating a new build job, testing against 1.0.0 ....
(In reply to comment #5) > We do not plan to have an SR2 build for Xpand and I don't think that this bug > is worthy to have one considering the effort for branching, backporting, > creating a new build job, testing against 1.0.0 .... Even if this bug is worthy enough, we can't do the whole effort, cause it just too late ...
Bug resolved before Xpand 1.2 release date => Closing
