[jira] [Commented] (TRB-85) Nested Templates output reversed

["Georg (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TRB-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263727#comment-13263727 ] 

Georg commented on TRB-85:
--------------------------

doing more tests and debugging it seems that it is sufficient instead to add a counter to handle buffering.

As I am using the old jetspeed 1.6 framework, which is on top of turbine framework this seems not necessary otherwise.

Changes are in class org.apache.turbine.services.velocity.TurbineVelocityService

add class variable intCount = 0;.

in executeRequest(Context, String, Writer)
intCount++;
Velocity.mergeTemplate(filename, encoding, context, writer);
intCount--;

Then check in the flush condition in in handleRequest(Context, String, OutputStream):

if (intCount == 0 && writer != null)
// flush

This seems not to be very elegant, but at least the templates are all rendered in the right order.

                
> Nested Templates output reversed
> --------------------------------
>
>                 Key: TRB-85
>                 URL: https://issues.apache.org/jira/browse/TRB-85
>             Project: Turbine
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: Core 4.0-M1
>         Environment: Windows XP, 
> java version "1.6.0_13"
> Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
> Java HotSpot(TM) Server VM (build 11.3-b02, mixed mode)
> Tomcat 6.0.18_03
>            Reporter: Georg Kallidis
>         Attachments: TurbineVelocityServices.patch
>
>
> Using (nested) calls in screen template the output (of the templates) seems to be reversed, i.e. the latest called templates are outputted first (lifo). 
> This may be due to that org.apache.turbine.services.velocity.TurbineVelocityService.handleRequest(Context, String) is implemented such, that each invocation creates a new instance of a java.io.OutputStreamWriter.OutputStreamWriter(OutputStream, String), which velocity then is writing to. May be the exact reason should be investigated in more detail. No test is available at the moment.
> This could be solved by providing a concurrent safe instance variable of OutputStreamWriter to be used in this method (handleRequest).
> Cft. http://mail-archives.apache.org/mod_mbox/turbine-dev/201109.mbox/%3C4E67C58C.5020804@apache.org%3E
> A patch could be attached later ..

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira