You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@reverycodes.com> on 2004/07/06 22:44:24 UTC
Cocoon JSR 168 Portlet in Cocoon Portal
Hi all,
I have successfully deployed Cocoon JSR-168 Portlet into Cocoon Portal.
Now, you can deploy your portlets implemented using Cocoon into Cocoon's
own portal.
There is a very simple demo of the Cocoon JSR-168 portlet included, just
go to the "JSR168" tab in the portal block demo. The only thing you need
to do before running demo is to comment out implementation of the
checkEnvironment() method in the EnvironmentHelper:
Index:
src/java/org/apache/cocoon/environment/internal/EnvironmentHelper.java
===================================================================
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/environment/internal/EnvironmentHelper.java,v
retrieving revision 1.3
diff -u -r1.3 EnvironmentHelper.java
---
src/java/org/apache/cocoon/environment/internal/EnvironmentHelper.java
29 May 2004 17:39:38 -0000 1.3
+++
src/java/org/apache/cocoon/environment/internal/EnvironmentHelper.java
6 Jul 2004 20:42:33 -0000
@@ -288,6 +288,7 @@
public static void checkEnvironment(Logger logger)
throws Exception {
// TODO (CZ): This is only for testing - remove it later on
+ /*
final EnvironmentStack stack =
(EnvironmentStack)environmentStack.get();
if (stack != null && !stack.isEmpty() ) {
logger.error("ENVIRONMENT STACK HAS NOT BEEN CLEANED
PROPERLY");
@@ -295,6 +296,7 @@
+"Please report this (if
possible together with a test case) "
+"to the Cocoon developers.");
}
+ */
}
/**
Carsten, can you shed more light as to what will be the best course for
this?
Vadim
RE: Cocoon JSR 168 Portlet in Cocoon Portal
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Looks good to me!
Thanks
Carsten
> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim@reverycodes.com]
> Sent: Thursday, July 08, 2004 2:43 PM
> To: dev@cocoon.apache.org
> Subject: Re: Cocoon JSR 168 Portlet in Cocoon Portal
>
> Carsten Ziegeler wrote:
>
> >Vadim Gritsenko wrote:
> >
> >
> >>It's actually very easy to reproduce:
> >>1. cvs up
> >>2. build clean; build
> >>3. cocoon servlet
> >>4. http://localhost:8888/samples/blocks/portal/portal
> >>5. login
> >>6. JSR-168 tab
> >>
> >>Exception is printed neatly within "JSR-168 Cocoon Portlet"
> >>content pane.
> >>
> >>Please bear in mind, call stack here is the following:
> >> CocoonServlet
> >> Cocoon (1)
> >> Treeprocessor, ...
> >> CopletSource
> >> ManagedCocoonPortlet
> >> Cocoon (2)
> >> EnvironmentHelper
> >>
> >>Where, (1) and (2) are the same instance of the Cocoon
> class, on the
> >>same thread. I think that's why it is confused. Here is
> head of trace.
> >>
> >>
> >>
> >Ah, ok, than life is much simpler :)
> >The check currently assumes that on method entry the stack stored in
> >the thread local is empty. Thus it checks on exit if the
> stack is empty
> >again.
> >We could store the current number of elements in the stack on method
> >entry and check if the stack has the same size on exit. This
> would just
> >be a local int variable.
> >WDYT?
> >
> >
>
> Done, please double check :-)
>
> Demo works out of the box now.
>
> Vadim
>
>
Re: Cocoon JSR 168 Portlet in Cocoon Portal
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
>Vadim Gritsenko wrote:
>
>
>>It's actually very easy to reproduce:
>>1. cvs up
>>2. build clean; build
>>3. cocoon servlet
>>4. http://localhost:8888/samples/blocks/portal/portal
>>5. login
>>6. JSR-168 tab
>>
>>Exception is printed neatly within "JSR-168 Cocoon Portlet"
>>content pane.
>>
>>Please bear in mind, call stack here is the following:
>> CocoonServlet
>> Cocoon (1)
>> Treeprocessor, ...
>> CopletSource
>> ManagedCocoonPortlet
>> Cocoon (2)
>> EnvironmentHelper
>>
>>Where, (1) and (2) are the same instance of the Cocoon class,
>>on the same thread. I think that's why it is confused. Here
>>is head of trace.
>>
>>
>>
>Ah, ok, than life is much simpler :)
>The check currently assumes that on method entry the stack
>stored in the thread local is empty. Thus it checks on exit
>if the stack is empty again.
>We could store the current number of elements in the stack
>on method entry and check if the stack has the same size
>on exit. This would just be a local int variable.
>WDYT?
>
>
Done, please double check :-)
Demo works out of the box now.
Vadim
RE: Cocoon JSR 168 Portlet in Cocoon Portal
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
>
> It's actually very easy to reproduce:
> 1. cvs up
> 2. build clean; build
> 3. cocoon servlet
> 4. http://localhost:8888/samples/blocks/portal/portal
> 5. login
> 6. JSR-168 tab
>
> Exception is printed neatly within "JSR-168 Cocoon Portlet"
> content pane.
>
> Please bear in mind, call stack here is the following:
> CocoonServlet
> Cocoon (1)
> Treeprocessor, ...
> CopletSource
> ManagedCocoonPortlet
> Cocoon (2)
> EnvironmentHelper
>
> Where, (1) and (2) are the same instance of the Cocoon class,
> on the same thread. I think that's why it is confused. Here
> is head of trace.
>
Ah, ok, than life is much simpler :)
The check currently assumes that on method entry the stack
stored in the thread local is empty. Thus it checks on exit
if the stack is empty again.
We could store the current number of elements in the stack
on method entry and check if the stack has the same size
on exit. This would just be a local int variable.
WDYT?
Carsten
Re: Cocoon JSR 168 Portlet in Cocoon Portal
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
>Vadim Gritsenko wrote:
>
>
>>There is a very simple demo of the Cocoon JSR-168 portlet
>>included, just go to the "JSR168" tab in the portal block
>>demo. The only thing you need to do before running demo is to
>>comment out implementation of the
>>checkEnvironment() method in the EnvironmentHelper:
>>
>>
...
>>Carsten, can you shed more light as to what will be the best
>>course for this?
>>
>>
>>
>Argh, ok, perhaps we can finally find the bug with this!
>The checkEnvironment is an integrated "test" to see if something went
>wrong with the internal environment handling. So if this method
>logs the exception, something went wrong :)
>
>We have an internal stack, bound as a thread local variable, that keeps
>track of the current environment and sitemap. So, if you enter
>a sitemap, the current environment and sitemap processor are pushed
>onto the stack and when the sitemap is left, the values are taken
>from the stack.
>The checkEnvironment() method checks at the end of the processing if the
>stack is empty. If not, something has not been taken from stack.
>
>Now, this gets more complicated, when internal pipeline calls are used.
>As these run in the same thread, the environment of the internal pipeline
>and of the external call are both on the same stack. An index for
>each pipeline keeps track of which environment belongs to which pipeline.
>
>It seems that the problem arises when this index somehow gets confused
>or, when something is not taken from the stack.
>
>I checked the code several times, but push and pop always come in a pair,
>so I'm a little bit clueless :)
>Is the message reproducable with every coplet? What do I have to do,
>to reproduce it?
>
>
It's actually very easy to reproduce:
1. cvs up
2. build clean; build
3. cocoon servlet
4. http://localhost:8888/samples/blocks/portal/portal
5. login
6. JSR-168 tab
Exception is printed neatly within "JSR-168 Cocoon Portlet" content pane.
Please bear in mind, call stack here is the following:
CocoonServlet
Cocoon (1)
Treeprocessor, ...
CopletSource
ManagedCocoonPortlet
Cocoon (2)
EnvironmentHelper
Where, (1) and (2) are the same instance of the Cocoon class, on the
same thread. I think that's why it is confused. Here is head of trace:
org.apache.cocoon.ProcessingException: Environment stack has not been cleaned up properly. Please report this (if possible together with a test case) to the Cocoon developers.
at org.apache.cocoon.environment.internal.EnvironmentHelper.checkEnvironment(EnvironmentHelper.java:294)
at org.apache.cocoon.Cocoon.process(Cocoon.java:692)
at org.apache.cocoon.portlet.ManagedCocoonPortlet.render(ManagedCocoonPortlet.java:557)
at org.apache.cocoon.portal.pluto.factory.LocalPortletInvokerImpl.render(LocalPortletInvokerImpl.java:140)
at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:103)
at org.apache.cocoon.portal.coplet.adapter.impl.PortletAdapter.streamContent(PortletAdapter.java:168)
at org.apache.cocoon.portal.coplet.adapter.impl.AbstractCopletAdapter.toSAX(AbstractCopletAdapter.java:128)
at org.apache.cocoon.portal.source.CopletSource.toSAX(CopletSource.java:168)
at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:134)
at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:114)
at org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElement(CIncludeTransformer.java:545)
Vadim
RE: Cocoon JSR 168 Portlet in Cocoon Portal
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
>
> Hi all,
>
> I have successfully deployed Cocoon JSR-168 Portlet into
> Cocoon Portal.
> Now, you can deploy your portlets implemented using Cocoon
> into Cocoon's own portal.
Cool!!
>
> There is a very simple demo of the Cocoon JSR-168 portlet
> included, just go to the "JSR168" tab in the portal block
> demo. The only thing you need to do before running demo is to
> comment out implementation of the
> checkEnvironment() method in the EnvironmentHelper:
>
> Index:
> src/java/org/apache/cocoon/environment/internal/EnvironmentHelper.java
> ===================================================================
> RCS file:
> /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/environment/in
> ternal/EnvironmentHelper.java,v
> retrieving revision 1.3
> diff -u -r1.3 EnvironmentHelper.java
> ---
> src/java/org/apache/cocoon/environment/internal/EnvironmentHel
> per.java
> 29 May 2004 17:39:38 -0000 1.3
> +++
> src/java/org/apache/cocoon/environment/internal/EnvironmentHel
> per.java
> 6 Jul 2004 20:42:33 -0000
> @@ -288,6 +288,7 @@
> public static void checkEnvironment(Logger logger)
> throws Exception {
> // TODO (CZ): This is only for testing - remove it later on
> + /*
> final EnvironmentStack stack =
> (EnvironmentStack)environmentStack.get();
> if (stack != null && !stack.isEmpty() ) {
> logger.error("ENVIRONMENT STACK HAS NOT BEEN
> CLEANED PROPERLY"); @@ -295,6 +296,7 @@
> +"Please report
> this (if possible together with a test case) "
> +"to the Cocoon
> developers.");
> }
> + */
> }
>
> /**
>
>
> Carsten, can you shed more light as to what will be the best
> course for this?
>
Argh, ok, perhaps we can finally find the bug with this!
The checkEnvironment is an integrated "test" to see if something went
wrong with the internal environment handling. So if this method
logs the exception, something went wrong :)
We have an internal stack, bound as a thread local variable, that keeps
track of the current environment and sitemap. So, if you enter
a sitemap, the current environment and sitemap processor are pushed
onto the stack and when the sitemap is left, the values are taken
from the stack.
The checkEnvironment() method checks at the end of the processing if the
stack is empty. If not, something has not been taken from stack.
Now, this gets more complicated, when internal pipeline calls are used.
As these run in the same thread, the environment of the internal pipeline
and of the external call are both on the same stack. An index for
each pipeline keeps track of which environment belongs to which pipeline.
It seems that the problem arises when this index somehow gets confused
or, when something is not taken from the stack.
I checked the code several times, but push and pop always come in a pair,
so I'm a little bit clueless :)
Is the message reproducable with every coplet? What do I have to do,
to reproduce it?
Carsten