redirect handling, environment handling, etc.

[Marco Rolappe <m_...@web.de>]

in the beginning I was just trying to hunt down unreleased components
problems, but met some internal problems on the way.

- adding state checks to CocoonComponentManager showed that there would be
lookup()s and release()s when the CCM was already disposed, it also helped
track down some other issues

- as I understand it (documentation is sparse) environment processing is
supposed to be like:
	- CCM.startProcessing(env), not nested
		- CCM.enterEnvironment(env, manager, processor), multiple entry if
properly nested
			- processing
		- CCM.leaveEnvironment()
	- CCM.endProcessing(env, processKey)

	- the 'scope' created by start/endProcessing and identified by the process
key is used at the end to cleanup, e.g. release the source resolver used by
environments (Environment implements SourceResolver)

- CCM.startProcessing doesn't check whether processing already started and
might simply overwrite the process key in the environment's object model,
which in turn means there would be cleanup problems

- when handling a cocoon:/ redirect a new environment
(ForwardEnvironmentWrapper) is created; this, however, includes cloning the
environment's object, which also includes the process key. given the above
description of enviroment processing, there would have to be a
start/endProcessing for the new environment, which there currently isn't.
this implies that the preparation/cleanup normally done (via
CCM.startProcessing->env.startingProcessing and
CCM.endProcessing->env.finishProcessing) for environment processing doesn't
occur here. the process key should be stored somewhere else, maybe in an
environment's attribute. this would at least enable to cleanup.

- given the correct cleanup mentioned before there's another problem;
suppose the following sitemap:
...
		<map:match pattern="redir-src">
			<map:redirect-to uri="cocoon:/the-src"/>
		</map:match>

		<map:match pattern="the-src">
			<map:generate src="sitemap.xmap"/>

			<map:serialize type="xml"/>
		</map:match>
...

a forward environment is created for 'the-src' and is passed as resolver to
the FileGenerator generating 'sitemap.xmap'. the problem is that the forward
environment would die (and be cleaned up) directly after redirect
processing.


<irony>but now I actually don't know if these are really problems or this is
intended behavior to save some lines of code or whatever</irony> ;-)