Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <40ED4156.2080807@reverycodes.com>
Date: Thu, 08 Jul 2004 08:43:02 -0400
From: Vadim Gritsenko <vadim@reverycodes.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7) Gecko/20040616
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Cocoon JSR 168 Portlet in Cocoon Portal
References: <OFAE03C889.AA93D227-ONC1256ECB.00262AF8@sundn.de>
In-Reply-To: <OFAE03C889.AA93D227-ONC1256ECB.00262AF8@sundn.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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