cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Pfingsthorn" <m.pfingsth...@hippo.nl>
Subject RE: environment errors
Date Thu, 02 Mar 2006 12:05:23 GMT


Carsten Ziegeler [mailto:cziegeler@apache.org]
> Max Pfingsthorn schrieb:
> > Hi!
> > 
> > Okay, I traced this one to the 
> o.a.c.environment.wrapper.EnvironmentWrapper
> > thank god for debuggers). That one does not implement 
> release(Source)
> itself,
> >so the superclass is used, but since it is a wrapper, it is 
> not initialized to 
> >have a source resolver itself! I am not sure what this class 
> is used for, but can I 
> >just forward the call to the wrapped environment like some 
> of the other
> methods do?
> > 
> Hmm, no, I think this is then just a workaround for the real problem.
> If the source resolver is null in release it either means that the
> resolveURI was never called before, so a source is tried to 
> be released
> on a different env than it was looked up from. Or in the other case,
> finishProcessing() has been called prior to the release 
> method. Then the
> order of method calls is wrong.
> 
> Can you come up with a test case?

Well, there are two errors here, actually. The one Jean-Baptiste commented on and the one
I traced. Both are very similar, and seem to be caused by a similar problem...

In Cocoon.process, in the last finally block, we call

CocoonComponentManager.leaveEnvironment();
CocoonComponentManager.endProcessing(environment, key);

leaveEnvironment pops the environment stack while endProcessing will call release (which in
turn calls recycle) on all components, which in turn calls CocoonComponentManager.removeFromAutomaticRelease(Component)
which tries to acces the environment stack, which is empty.

The other error is caused by endProcessing calling env.finishingProcessing(); before desc.release();.

Okay, I think I got it now. The CocoonComponentManager.addComponentForAutomaticRelease will
actually add this component to the root environment (line 464, in 2.1.8) because it does stack.get(0),
which is the lowest stack item. This happens for each sitemap source in the init() method.
Since env.finishingProcessing() is called by each sitemap source (through CocoonComponentManager.leaveEnvironment())
and removeFromAutomaticRelease() is done after all the processing, the environment the components
from the deeper sitemap sources will already have been ended.
It would be better to add them to the top of the stack.

I think this would solve both problems, because both occur in EnvironmentDescription.release().

I'll try to come up with a simple test case, but right now I have a headache from two days
of sitting in front of the debugger... I'll let you know if changing this one line in CocoonComponentManager.addComponentForAutomaticRelease
helped. Actually its changing 

final EnvironmentStack.Item objects = (EnvironmentStack.Item)stack.get(0);

into

final EnvironmentStack.Item objects = (EnvironmentStack.Item)stack.get();

I'll take some painkillers now.

max

Mime
View raw message