You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Thomas Vandahl <tv...@apache.org> on 2011/08/28 12:33:50 UTC
Turbine 4.0 Migration Guide
Hi folks,
I started to fill up the Migration Guide for upgrading a Turbine 2.3.3
application to Turbine 4.0M1. See the Turbine Wiki at
http://wiki.apache.org/turbine/Turbine4/Turbine4.0M1/Migrate233
I would like to invite everyone to add your own experiences to the page.
Feedback to the topics already covered is also very welcome.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
For additional commands, e-mail: user-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
Re: Antwort: Turbine 4.0 Migration Guide
Posted by Thomas Vandahl <tv...@apache.org>.
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>.
yes.
In turbine-2.3.3 it is in
org.apache.turbine.modules.screens.VelocityDirectScreen.buildTemplate
(RunData)
TurbineVelocity.handleRequest(context,prefix + templateName,data.
getOut());
In contrast in turbine-4.0-M1.jar it is:
TurbineVelocity.handleRequest(context, prefix + templateName,
data.getResponse().getOutputStream());
The same for the doBuild method(s) in
org.apache.turbine.modules.layouts.VelocityDirectLayout.
org.apache.turbine.modules.layouts.VelocityOnlyLayout has new
getOutputStream
while in turbine-2.3.3
data.getOut().print(TurbineVelocity .handleRequest(context, prefix
+ templateName));
org.apache.turbine.services.jsp.TurbineJspService.handleRequest(RunData,
String, boolean) has
old: data.getOut().flush();
new: data.getResponse().getWriter().flush();
You could find further usages of data.getOut(), e.g. in
org.apache.turbine.modules.layouts.VelocityXslLayout,
org.apache.turbine.services.jsp.util.JspNavigation.setTemplate(String),
org.apache.turbine.services.jsp.util.JspScreenPlaceholder.exec().
Best, Georg.
Von: Thomas Vandahl <tv...@apache.org>
An: Turbine Developers List <de...@turbine.apache.org>
Datum: 31.08.2011 13:00
Betreff: Re: Antwort: Turbine 4.0 Migration Guide
On 30.08.11 09:47, Georg Kallidis wrote:
> With this release I experience with the handling of the velocity
> templates a similar problem as discussed in
>
> http://wiki.apache.org/turbine/Turbine2/VelocityOnlyLayout getting the
> error java.lang.IllegalStateException: getOutputStream() has already
> been called for this response.
I'm not sure if I understand what's going wrong. The handling of these
topics was not supposed to be changed from 2.3.3 to 4.0. I tried to
merge the changes that happened in 2.3.x back into the trunk but some of
them might have slipped through. Could you please check what the code
differences are between 2.3.3 and 4.0 in this area?
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Antwort: Turbine 4.0 Migration Guide
Posted by Thomas Vandahl <tv...@apache.org>.
On 30.08.11 09:47, Georg Kallidis wrote:
> With this release I experience with the handling of the velocity
> templates a similar problem as discussed in
>
> http://wiki.apache.org/turbine/Turbine2/VelocityOnlyLayout getting the
> error java.lang.IllegalStateException: getOutputStream() has already
> been called for this response.
I'm not sure if I understand what's going wrong. The handling of these
topics was not supposed to be changed from 2.3.3 to 4.0. I tried to
merge the changes that happened in 2.3.x back into the trunk but some of
them might have slipped through. Could you please check what the code
differences are between 2.3.3 and 4.0 in this area?
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Antwort: Turbine 4.0 Migration Guide
Posted by Georg Kallidis <ge...@fu-berlin.de>.
Hi,
in reply to the migration guide, thanks a lot for the information.
I have a jetspeed-1 based turbine webapp and tried to do an update. I am
already using turbine 2.3.3.
With this release I experience with the handling of the velocity
templates a similar problem as discussed in
http://wiki.apache.org/turbine/Turbine2/VelocityOnlyLayout getting the
error java.lang.IllegalStateException: getOutputStream() has already
been called for this response.
My Settings in TurbineResource.properties are:
services.VelocityService.default.screen=VelocityDirectScreen
services.VelocityService.default.layout = VelocityDirectLayout
As these classes use TurbineVelocity.handleRequest(context, template,
rundata.getResponse().getOutputStream()) and the caching seems to be
deprecated I changed in my controllers/processors from
TurbineVelocity.handleRequest(context, template, rundata.getOut());
TurbineVelocity.handleRequest(context, template, rundata.getResponse
().getOutputStream());
The error disappears, but the sequence of the loaded templates is
reversed (more exactly the templates loaded from the screen Home.vm, the
navigations templates seem to be in the right order), if the jetspeed-1
loading mechanism tries to load the templates. This may be logical, as
the getResponse().getOutputStream() is only flushed after the last
template is called and velocity push/pops the templates from a stack.
I have overwritten the TurbineVelocityService class setting the
OutputStreamWriter writer to a class variable and using this variable in
the method
org.apache.jetspeed.services.velocity.DCTurbineVelocityService.handleRequest
(Context, String, OutputStream), checking for null:
public void handleRequest(Context context, String filename,
OutputStream output)
throws TurbineException
{
String charset = getCharSet(context);
try
{
if (writer == null)
writer = new OutputStreamWriter(output,
charset);
writer.flush();
executeRequest(context, filename, writer);
}
catch (Exception e)
{
renderingError(filename, e);
}
finally
{
try
{
if (writer != null)
{
writer.flush();
writer = null;
}
}
catch (Exception ignored)
{
// do nothing.
}
}
}
Doing this the problem seems to be resolved.
I get another error, if I have in the default
turbine-classic-pipeline.xml
<org.apache.turbine.pipeline.DetermineRedirectRequestedValve/>:
2011-08-29 14:24:44,889 [http-8093-6] DEBUG
DetermineRedirectRequestedValve - Output stream closed?
java.lang.Exception: Nothing to output
at
org.apache.turbine.pipeline.DetermineRedirectRequestedValve.redirectRequested
(DetermineRedirectRequestedValve.java:102)
at
org.apache.turbine.pipeline.DetermineRedirectRequestedValve.invoke
(DetermineRedirectRequestedValve.java:59)
The reason are, that two deprecated variables have their default
value ??
Thanks for any discussion.
Best regards,
Georg
Von: Thomas Vandahl <tv...@apache.org>
An: Turbine Developers List <de...@turbine.apache.org>, Turbine Users List <us...@turbine.apache.org>
Datum: 28.08.2011 12:35
Betreff: Turbine 4.0 Migration Guide
Hi folks,
I started to fill up the Migration Guide for upgrading a Turbine 2.3.3
application to Turbine 4.0M1. See the Turbine Wiki at
http://wiki.apache.org/turbine/Turbine4/Turbine4.0M1/Migrate233
I would like to invite everyone to add your own experiences to the page.
Feedback to the topics already covered is also very welcome.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Antwort: Turbine 4.0 Migration Guide
Posted by Thomas Vandahl <tv...@apache.org>.
On 31.08.11 10:59, Georg Kallidis wrote:
> The next problem is that in
> org.apache.turbine.services.jsp.TurbineJspService.handleRequest(RunData,
> String, boolean) the variable relativeTemplateName has its leading
> slashes (if any) removed. But this leads to an IllegalArgumentException
> from org.apache.catalina.core.ApplicationContext.getRequestDispatcher,
> which requires a leading slash. If relativeTemplateName has its leading
> slash again reset the response is successfull.
AFAICS, this behavior was already in Turbine 2.3.3. At least this
special part of the code is identical.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Antwort: Turbine 4.0 Migration Guide
Posted by Georg Kallidis <ge...@fu-berlin.de>.
Hello,
another (two) remarks:
If I include JSPs into a velocity based template system, I get (nothing
else changed) the exception java.lang.IllegalStateException:
getOutputStream() has already been called for this response.
This may be because data.getResponse().getOutputStream() is already
called from the velocity handlers (VelocityDirectScreen,... calling
org.apache.turbine.services.velocity.TurbineVelocity.handleRequest
(Context, String, OutputStream).
Only if I use an buffered version of the response
(org.apache.jetspeed.services.jsp.HttpBufferedResponse.HttpBufferedResponse
(HttpServletResponse, PrintWriter)) the exception
java.lang.IllegalStateException is not thrown.
The next problem is that in
org.apache.turbine.services.jsp.TurbineJspService.handleRequest(RunData,
String, boolean) the variable relativeTemplateName has its leading
slashes (if any) removed. But this leads to an IllegalArgumentException
from org.apache.catalina.core.ApplicationContext.getRequestDispatcher,
which requires a leading slash. If relativeTemplateName has its leading
slash again reset the response is successfull.
May be this is a bug.
With this two changes applied I could indeed load the JSPs.
Best regards,
Georg
Von: Thomas Vandahl <tv...@apache.org>
An: Turbine Developers List <de...@turbine.apache.org>, Turbine Users List <us...@turbine.apache.org>
Datum: 28.08.2011 12:35
Betreff: Turbine 4.0 Migration Guide
Hi folks,
I started to fill up the Migration Guide for upgrading a Turbine 2.3.3
application to Turbine 4.0M1. See the Turbine Wiki at
http://wiki.apache.org/turbine/Turbine4/Turbine4.0M1/Migrate233
I would like to invite everyone to add your own experiences to the page.
Feedback to the topics already covered is also very welcome.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org