Daniel Fagerstrom pisze: > Grzegorz Kossakowski skrev: >> Giacomo Pati pisze: >> >>> Yes, clean my M2 repo. >>> >>> >>>> of problematic behaviour in order to help anyhow. >>>> >>> Still have the problems. With scpre="request" I got the stack trace >>> after the first request found >>> at http://people.apache.org/~giacomo/request-log4j-2.log >>> >> >> I fear that we got stuck. Without working code exhibiting your problem >> I cannot help any further. >> > Don't know if you are going to like it ;) Have you studied how you prove > algorithm correctness yet?
Yes I have. We have quite stuffed programme at Warsaw University. > If not, the idea is that you give a formal > definition of the precondition of the algorithm, what is true about > input data before you run the algorithm. You also describe the post > condition, what is supposed to be true about the output of the > algorithm. The you use your creativity and state an invariant, something > that will be true about the state variables of the algorthm at all time > through the execution. Then the remaining and rather mechanical step is > to show that the precondition and the operations leads to the invariant, > that loops or recursions preserve the invariant and that the invariant > together with the stop condition leads to the postcondition. > > OK, doing the above in a formal way, would require an completely > unrealistic amount of work for the object model and the pipeline scope. > But following the general scheme in an unformal way is often quite > helpful for understanding and describing complex algorthms. > > So, getting to the point, what I propose is that you describe in a > semiformal way what is supposed to be true about stack and other state > before enetering the scope, during the scope and when leaving it. This > will be helpful both for you and for the rest of us for being able to > see if your approach and code is correct. Yep, I agree. I've done such analysis to some extent when proposing[1] pipelineComponent scope and then discussing details in that thread. > Now, the above can seem like a rather indirect and inneficient way to > find the problem behind the bug that Giacomo found. For code in general > it isn't the way to go. But for things like building execution machines > for languages (as in the current case) my experience strongly suggest > that what I propose is the most efficient way to go. What I found up to date with Giacomo's trouble is that most of Cocooners seems to consider servlet: as easy replacement for cocoon: source. From what I see most people think that they can just setup blocks and use find&replace in their IDE and everything will be working using SSF. The point is that's not true. At this point, servlet source does *NOT* forward environment (including OM) to called servlet. I repeat this: it does NOT forward anything, servlet requests are virgin ones. Of course, when using old code that does not take advantage of Spring scopes one will be able to reuse anything she likes between servlets but OM is a new code that *DOES* take advantage of Spring scopes. I put really a lot of effort in order to clarify things and provide overall picture of current state of our code in my RT e-mail. What I found disheartening was the fact that no Cocoon developer bothered to say at last: "Grzegorz, I don't understand any paragraph of your e-mail, you just screwed it up". Then I wouldn't be surprised by people surprised by current implementation. Sorry for little offending words but I'm really tired repeating the same thing around ten times and being blamed in the end. I hope that we can summarize current situation, cut new release candidate of C2.2 and return back to whiteboard for a while. [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74560 -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
