Re: Cocoon JSR 168 Portlet in Cocoon Portal

[Vadim Gritsenko]

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