Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 329520

Summary:	FileHandle.getBuffer() does not return whole buffer in PostProcessor
Product:	[Modeling] M2T	Reporter:	sergej shafarenka <beworker>
Component:	Xpand	Assignee:	Project Inbox <m2t.xpand-inbox>
Status:	CLOSED FIXED	QA Contact:
Severity:	major
Priority:	P3	CC:	dennis.huebner, karsten.thoms, sebastian.zarnekow, sven.efftinge
Version:	1.0.0	Flags:	sven.efftinge: indigo+
Target Milestone:	M6
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description sergej shafarenka

2010-11-05 05:12:42 EDT

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

Comment 1 Karsten Thoms

2011-02-15 16:52:18 EST

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.

Comment 2 Sven Efftinge

2011-02-15 17:02:50 EST

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.

Comment 3 Sven Efftinge

2011-02-15 17:04:58 EST

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?

Comment 4 Karsten Thoms

2011-02-15 17:47:27 EST

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.

Comment 5 Sebastian Zarnekow

2011-02-16 02:52:23 EST

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 ....

Comment 6 Dennis Huebner

2011-02-16 03:12:17 EST

(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 ...

Comment 7 Karsten Thoms

2013-02-21 08:09:48 EST

Bug resolved before Xpand 1.2 release date => Closing