Another nuance I see is that a form keeps displaying the old input
values.. when normally those are cleared after a form submits. So I'm
assuming that the ValidationTracker is not being properly cleared, so
maybe some code that clears the validationTracker isn't "setting" it
afterwards.
that is, if my theory and ideas, so late in the night are close to true. :)
food for thought.
fernando
Fernando Padilla wrote:
So.. I need confirmation on an HttpSession expected behavior, to see if
there is an annoyance with @ApplicationState and @Persist:
a) Object value = session.getAttribute( key );
b) value.modifyMe();
c) session.setAttribute( key, value );
It was my understanding (maybe really old servlet spec), that sessions
would not guarantee changes in attributes (line b) to be property
persisted unless you called setAttribute directly (line c) to tell it
the value has changed. This was to support persisted or distributed
sessions that might be dealing with copies of values intead of a single
centralized instance.
If this is the case, then modifications to ApplicationState objects
require you to explicitly set them again in order for modifications to
actually take:
@ApplicationState
private MyASO aso;
a) MyASO tmp = aso;
b) tmp.modifyMe();
c) aso = tmp;
Most session stores that people use (default ones for tomcat/jetty) have
in memory caches, and we probably do lots of testing in single boxes,
not distributed session stores. But I just ran into this behavior
trying to use a Memcached backed session store: I noticed that changes
to our ASOs were not being stored in the session store. (yes I just
implemented the memcached session store)
So some questions for discussion:
1) do you agree with the spec as I stated above, and thus the resulting
bug? Or is the session store suppose to be really smart and autodetect
when changes occur, or really inefficient and write back all attributes
that were loaded during the request?
2) Can tapestry do anything to help us out? To make this fool proof.
How easy would it be to implement a ASO modification checker, where
at the end of the request (before it clears variables), Tapestry woud
ask the ASO if it has been modified, and if so, set it for us?
3) The above behavior is theoretically present in @Persist as well, but
I have not tested it yet. How does @Persist track changes?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
