You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Thomas Vandahl <tv...@apache.org> on 2011/09/02 19:12:06 UTC
Re: Antwort: Turbine 4.0 Migration Guide
On 30.08.11 09:47, Georg Kallidis wrote:
> http://wiki.apache.org/turbine/Turbine2/VelocityOnlyLayout getting the
> error java.lang.IllegalStateException: getOutputStream() has already
> been called for this response.
[...]
> Doing this the problem seems to be resolved.
I think I got it now. The problem is that multiple calls to
data.getResponse().getOutputStream() happen at different places in
Turbine while getOut() was cached before. This makes me wonder how this
was meant to work in the first place.
I appreciate the fix for TurbineVelocityService. From what I understand,
however, this might lead to confusion between output streams when
multiple requests are being handled concurrently.
Which brings us back to the first question: How this was meant to work
without caching in the first place? Is anyone of the more experienced
people able to shed some light on this?
> I get another error, if I have in the default
> turbine-classic-pipeline.xml
>
> <org.apache.turbine.pipeline.DetermineRedirectRequestedValve/>:
[...]
> The reason are, that two deprecated variables have their default
> value ??
Yeah, right you are. This comparison is obviously wrong when the RunData
methods are being by-passed. Right now, I don't have an idea how to
solve this.
Thanks for your contribution. I didn't know that Turbine 2.3.3 would run
with JetSpeed at all. I wrote a JSR-286-Portlet bridge for Turbine to be
used in Liferay. Maybe we can share some experiences?
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Antwort: Re: Antwort: Turbine 4.0 Migration Guide
Posted by Thomas Vandahl <tv...@apache.org>.
On 07.09.11 14:25, Georg Kallidis wrote:
> I changed the instance settings to
>
> private OutputStreamWriter getWriter() {
> return (OutputStreamWriter) threadLocal.get();
> }
>
> private void setWriter(OutputStreamWriter writer) {
> threadLocal.set(writer);
> }
>
> private static ThreadLocal<OutputStreamWriter> threadLocal =
> new ThreadLocal<OutputStreamWriter>();
>
> and the method
>
> public void handleRequest(Context context, String filename,
> OutputStream output)
> throws TurbineException
> {
> String charset = getCharSet(context);
>
> try
> {
> if (getWriter() == null)
> setWriter(new OutputStreamWriter(output,
> charset));
>
> executeRequest(context, filename, getWriter());
> }
> catch (Exception e)
> {
> renderingError(filename, e);
> }
> finally
> {
> try
> {
> if (getWriter() != null)
> {
> getWriter().flush();
> setWriter(null);
>
> }
> }
> catch (Exception ignored)
> {
> // do nothing.
> }
> }
> }
>
> and this should solve the concurrency issue.
Would you please open a JIRA ticket and attach the patch? You need to
check the CLA checkbox to submit this formally.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Antwort: Re: Antwort: Turbine 4.0 Migration Guide
Posted by Georg Kallidis <ge...@fu-berlin.de>.
I changed the instance settings to
private OutputStreamWriter getWriter() {
return (OutputStreamWriter) threadLocal.get();
}
private void setWriter(OutputStreamWriter writer) {
threadLocal.set(writer);
}
private static ThreadLocal<OutputStreamWriter> threadLocal =
new ThreadLocal<OutputStreamWriter>();
and the method
public void handleRequest(Context context, String filename,
OutputStream output)
throws TurbineException
{
String charset = getCharSet(context);
try
{
if (getWriter() == null)
setWriter(new OutputStreamWriter(output,
charset));
executeRequest(context, filename, getWriter());
}
catch (Exception e)
{
renderingError(filename, e);
}
finally
{
try
{
if (getWriter() != null)
{
getWriter().flush();
setWriter(null);
}
}
catch (Exception ignored)
{
// do nothing.
}
}
}
and this should solve the concurrency issue.
Best regards, Georg
Von: "Georg Kallidis" <ge...@fu-berlin.de>
An: "Turbine Developers List" <de...@turbine.apache.org>
Datum: 05.09.2011 11:09
Betreff: Antwort: Re: Antwort: Turbine 4.0 Migration Guide
[concurrency]
the instance variable could be wrapped in a ThreadLocal. I´ll test
this.
[experiences]
-I updated a Jetspeed 1.6 (since 2008 retired) based webapp (which is
available for German universities, cft.
http://opendc.distributed-campus.org/) to Turbine 2.3.3 to be able to
update this core framework in the future (e.g. to this current milestone
update). This was done with not very much effort (the turbine migration
was quite helpful) in production end of last year. One thing I did not
change is the usage of the deprecated class DynamicURI as this was used
very extensively used in many templates (indeed its usefuleness comes
from the possibility to concatenate methods).
-Jetspeed 2 is of course a completely another beast (real portlet
container), although a migration guide for Jetspeed 1 exists. This was
not an option for this project.
We could share more about all this may be offlist?
Best regards, Georg
Von: Thomas Vandahl <tv...@apache.org>
An: Turbine Developers List <de...@turbine.apache.org>
Datum: 02.09.2011 19:13
Betreff: Re: Antwort: Turbine 4.0 Migration Guide
On 30.08.11 09:47, Georg Kallidis wrote:
> http://wiki.apache.org/turbine/Turbine2/VelocityOnlyLayout getting the
> error java.lang.IllegalStateException: getOutputStream() has already
> been called for this response.
[...]
> Doing this the problem seems to be resolved.
I think I got it now. The problem is that multiple calls to
data.getResponse().getOutputStream() happen at different places in
Turbine while getOut() was cached before. This makes me wonder how this
was meant to work in the first place.
I appreciate the fix for TurbineVelocityService. From what I understand,
however, this might lead to confusion between output streams when
multiple requests are being handled concurrently.
Which brings us back to the first question: How this was meant to work
without caching in the first place? Is anyone of the more experienced
people able to shed some light on this?
> I get another error, if I have in the default
> turbine-classic-pipeline.xml
>
> <org.apache.turbine.pipeline.DetermineRedirectRequestedValve/>:
[...]
> The reason are, that two deprecated variables have their default
> value ??
Yeah, right you are. This comparison is obviously wrong when the RunData
methods are being by-passed. Right now, I don't have an idea how to
solve this.
Thanks for your contribution. I didn't know that Turbine 2.3.3 would run
with JetSpeed at all. I wrote a JSR-286-Portlet bridge for Turbine to be
used in Liferay. Maybe we can share some experiences?
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Antwort: Re: Antwort: Turbine 4.0 Migration Guide
Posted by Georg Kallidis <ge...@fu-berlin.de>.
[concurrency]
the instance variable could be wrapped in a ThreadLocal. I´ll test
this.
[experiences]
-I updated a Jetspeed 1.6 (since 2008 retired) based webapp (which is
available for German universities, cft.
http://opendc.distributed-campus.org/) to Turbine 2.3.3 to be able to
update this core framework in the future (e.g. to this current milestone
update). This was done with not very much effort (the turbine migration
was quite helpful) in production end of last year. One thing I did not
change is the usage of the deprecated class DynamicURI as this was used
very extensively used in many templates (indeed its usefuleness comes
from the possibility to concatenate methods).
-Jetspeed 2 is of course a completely another beast (real portlet
container), although a migration guide for Jetspeed 1 exists. This was
not an option for this project.
We could share more about all this may be offlist?
Best regards, Georg
Von: Thomas Vandahl <tv...@apache.org>
An: Turbine Developers List <de...@turbine.apache.org>
Datum: 02.09.2011 19:13
Betreff: Re: Antwort: Turbine 4.0 Migration Guide
On 30.08.11 09:47, Georg Kallidis wrote:
> http://wiki.apache.org/turbine/Turbine2/VelocityOnlyLayout getting the
> error java.lang.IllegalStateException: getOutputStream() has already
> been called for this response.
[...]
> Doing this the problem seems to be resolved.
I think I got it now. The problem is that multiple calls to
data.getResponse().getOutputStream() happen at different places in
Turbine while getOut() was cached before. This makes me wonder how this
was meant to work in the first place.
I appreciate the fix for TurbineVelocityService. From what I understand,
however, this might lead to confusion between output streams when
multiple requests are being handled concurrently.
Which brings us back to the first question: How this was meant to work
without caching in the first place? Is anyone of the more experienced
people able to shed some light on this?
> I get another error, if I have in the default
> turbine-classic-pipeline.xml
>
> <org.apache.turbine.pipeline.DetermineRedirectRequestedValve/>:
[...]
> The reason are, that two deprecated variables have their default
> value ??
Yeah, right you are. This comparison is obviously wrong when the RunData
methods are being by-passed. Right now, I don't have an idea how to
solve this.
Thanks for your contribution. I didn't know that Turbine 2.3.3 would run
with JetSpeed at all. I wrote a JSR-286-Portlet bridge for Turbine to be
used in Liferay. Maybe we can share some experiences?
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org