[
https://issues.apache.org/jira/browse/TRB-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416923#comment-13416923
]
Georg Kallidis commented on TRB-85:
-----------------------------------
Update to my last comment: the code snippet does (with synchronization), what
expected, but as the inherent capabilities of Turbine are sufficient, I prefer
using them. By using again the deprecated (in Turbine 4.0) methods
org.apache.turbine.util.RunData.getOut() instead in combination with
appropriate layout and screens. I.e. what I am using now are just the classes
VelocityDirectLayout and VelocityDirectScreen in Turbine 2.3.3. They were very
misleadingly called like that, and indeed in T4 their behaviour changed to what
the class name promises. I just renamed the old classes to VelocityCachedLayout
and VelocityCachedScreen and I now get the expected result (the output is
flushed at the end, N.B. I am using the old jetspeed 1.6 framework on top of
Turbine).
I would plead to remove the deprecated tag for the Rundata.getOut() and linked
methods and allow for caching the layout and screen. At least to think about
it...
> 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/%[email protected]%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