cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Cocoon JSR 168 Portlet in Cocoon Portal
Date Wed, 07 Jul 2004 10:52:16 GMT
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:
   Cocoon (1)
    Treeprocessor, ...
       Cocoon (2)

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(
	at org.apache.cocoon.Cocoon.process(
	at org.apache.cocoon.portlet.ManagedCocoonPortlet.render(
	at org.apache.cocoon.portal.pluto.factory.LocalPortletInvokerImpl.render(
	at org.apache.pluto.PortletContainerImpl.renderPortlet(
	at org.apache.cocoon.portal.coplet.adapter.impl.PortletAdapter.streamContent(
	at org.apache.cocoon.portal.coplet.adapter.impl.AbstractCopletAdapter.toSAX(
	at org.apache.cocoon.portal.source.CopletSource.toSAX(
	at org.apache.cocoon.components.source.SourceUtil.toSAX(
	at org.apache.cocoon.components.source.SourceUtil.toSAX(
	at org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElement(


View raw message