Marco Rolappe wrote: > > > Unfortunately, an internal request/environment gets a copy of the > > parent object model, so it also gets the key in it's copy. > > So, in this case startProcessing() is legal and *must* > overwrite the > > key stored in the object model. > > but then I can't see the real point in protecting the > environment processing by a key. why not binding resource > looked up/used while processing/to be cleaned up to the > actual environment then?
Perhaps we are taking about different things here. The environment implementation and especially the wrapper implementation didn't allow it. For example, if you remove an attribute on the wrapper (or the child env), then this attribute is removed at the parent as well! This was done because of some flow stuff I think but makes it really dificult to get it right. Anyways, the basic idea is that the environment is independent from the processing, so the environment should not know anything about how the core organizes things. The current implementation is not optional but is not that easy changeable without loosing some compatibility. That's why we rewrote all of that for 2.2. > > In this aspect 2.2 is much better as only the key is stored in the > > object model, everything else is stored not reachable from > either the > > environment or the object model. So, it's much cleaner and safer. > > with everything else you mean request, response, ... objects? > I guess I'm going to take a look... ;-) > No, request etc. are of course still stored in the object model, but some internal objects for processing the request are not part of the object model any more. I even hope to remove the processing key from the object model in 2.2. I'm just waiting for some changes in the flow/redirector part and then I will hopefully finally clean up everything. I guess we have to rethink the forward/wrapper strategy in 2.2 as well. Carsten
