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: [email protected] > 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: [email protected] > > Subject: RE: environment errors > > > > > > > > > > Carsten Ziegeler [mailto:[EMAIL PROTECTED] > > > 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 > > >
