cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Myers <phan...@pirouline.sts.jhu.edu>
Subject EnvironmentWrapper.java
Date Wed, 12 Mar 2003 04:04:42 GMT
Hi Carsten,

Lengthy rational below; maybe just skip to the attachments.

Related to old bug 10281.  It's popped up again just as your commit comments 
said it would.  Thanks (and to Ugo) for fixing the ForwardRedirector problems too.
This is completely unrelated to the ForwardRedirector Problem/Fix.

When i posted a patch, i modified AbstractProcessingPipeline making it "smarter?".

"This patch gives the pipeline knowledge of which processor it belongs to when
the generator is set,  then reminds it which processor to use when the pipeline
is setup.  This corrects the problem.  I've only tested with the treeprocessor,
but i assume that if the compiled sitemap had the bug, this fix will pertain to
it as well."

You realized that this shouldn't be in the processing pipeline so you put it
in the environment wrapper.  My suspicion is that i was violating IoC by making
the pipeline aware of the processor it is contained in.

Anyway, all was good until the one method that happened to be called on the 
environment when entering a sitemap was removed in cleanup.  No matter where
you stick that thing in the environment wrapper, it's not going to work.  
EnvironmentWrapper.ChangeContext is called in mount node before the environment is 
entered in the ComponentManager (happens in TreeProcessor) and by the time 
changeToLastContext is called, the inner environment has already been left.

So...

Why not put a processor attribute in the environment from within 
TreeProcessor.processInternal()?

See attachments.  I didn't do anything with EnvironmentWrapper, but this should allow
you to remove all of the hacks.

Tim

Mime
View raw message