I just applied a fix; the test-case now runs without errors and other things still seem to work :) - AFAI can tell this fix shouldn't cause any unwanted site effects.

So, if it works, well...greetings to your project :)

Carsten

Carsten Ziegeler wrote:
Sylvain Wallez wrote:

Carsten Ziegeler wrote:



I don't understand what is this "last context": does it have to behave like a stack, or is it the context in which the internal pipeline has been built?


It is the context in which the internal pipeline will run; it's not a stack. Internal pipeline calls are done in two phases: the first one building the pipeline and the second on invoking the pipeline. As only during the first phase the tree processor is invoke, the environment context (or the location of the sitemap used for the pipeline) is lost. Therefore the environment wrapper stores the last sitemap used (which is currently the deepest sitemap used during processing).

And I think this is exactly the problem with the pass through, because with pass-through the sitemap that should be used for running the pipeline is not the deepest one, but a different one.
So, rethinking everything this could be fixed perhaps more easily than I thought. If the flow comes back from a sub sitemap without a match (pass through) then the last context of the wrapper should be overwritten with the current context.


I'm just testing a fix for this - stay tuned.


Also, what's the relation between a mount and subsequent internal pipelines. Each internal pipeline uses its own EnvironmentWrapper?

Yes, exactly.

So that would mean that the original HttpEnvironment has been modified?

No, the original environment should never be modified.

Carsten





Reply via email to