1) The initial way of storing it in the component. We (at least some
of us, I wasn't involved in this) decided this was too expensive in
terms of storage.
2) The old way of storing it in in the page. I'm very much against
this as it doesn't allow people to set messages in the constructor
(which I even though it myself somewhere), which imho is a crazy
limitation as storing in the page is an optimization over storing with
the component in the first place. What I also didn't like about the
way this was implemented was that messages were cleared up too late,
and were serialized as part of the page state on every request, even
if they already were rendered.
3) Storing it in a thread local temporarily (part of page).
Implemented this and was about to commit it, and was backwards
compatible with 2 with the exception that the cleanup was better and
it worked at construction time. But then people were arguing against
any use of thread locals and Jonathan argued he felt very strongly
about the session being the right place for this.
4) The session. See the current situation. It's still an optimization
over 1), which is conceptually the ideal situation. I think it works
best (besides 1 that is), but here the big issue is when to clean up;
do it aggressively (like I did) or more lenient (like it is now),
trusting all messages to be rendered and thus cleaned up at some
point. I'm for the agressive cleanup myself, but I thought more people
(you, Igor, Martijn) were for the lenient approach. Maybe I
misunderstood this.
i can't remember that i really discussed this or got involved into this.
I just read the code the last days and try to find possible bugs to solve
them
Lenient or agressive i don't care to much i think we should doe agressive
because
they shouldn't hang around for ever Especially now because we bind them to a
session
that never goes away!
But looking at the current code:
final Page page = RequestCycle.get().getResponsePage();
if (message.isRendered())
{
return true;
}
if (page != null)
{
Component reporter = message.getReporter();
if (reporter != null)
{
Page reporterPage = reporter.findPage();
return reporterPage != null && reporterPage.equals
(page);
}
}
notCleanedUpCounter.count++;
return false;
then it is possible that in some situations something hangs.
We only test for the response page. What happens if the error was reported
with
the request page? (and somebody did set another page as a response one)
Or if the component did report an error. But that component was also removed
from the page
after that (a component in a repeater for example) then findPage doesn't
work on the component.
But i think we can do option number 5:
Store them in the RequestCycle then we don't have to worry about anything
and we don't have to clear
then yes if you want feedback over request you need to use session based one
But looking at the code thats also now the case.
If a message != rendered but the page == response page it is still removed..
also a pro for the request cycle is that we don't have to look at the copy
on write list.
Because for session based feedback i don't mind to much..
johan
