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 Fri, 03 Mar 2006 10:59:06 GMT
Dear all,

sorry for this noise... It was my fault. I didn't release a source properly in one of my generators...

Jean-Baptiste, maybe you have the same problem?

Bye!
max

> -----Original Message-----
> From: Max Pfingsthorn 
> Sent: Thursday, March 02, 2006 13:10
> To: dev@cocoon.apache.org
> Subject: RE: environment errors
> 
> 
> ...nevermind. that didn't do the trick.
> 
> max
> 
> > -----Original Message-----
> > From: Max Pfingsthorn 
> > Sent: Thursday, March 02, 2006 13:05
> > To: dev@cocoon.apache.org
> > Subject: RE: environment errors
> > 
> > 
> > 
> > 
> > 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