feature of Orchestra; apps should use different
conversationContextIds for different windows. The locking is just a
safety measure for some odd corner cases, not a major user feature.
Regards,
Simon
Jacob Mathew schrieb:
It should be noted that the border case where the first request
creates
What is the motivation for setting a timeout for the context? Ultimately you
are interested in the deletion of beans in a conversation right? Can you not
achieve that by setting the timeouts on the conversations directly? Every
bean in a conversationContext is inside a conversation...
-Jacob
On
are stuck until I resume the
thread stuck at the breakpoint.
Any insights?
-Jacob Mathew
will not happen concurrently, which mean beans in a
conversation (access) scope do no, in general, need to be thread safe.
Explicit documentation of this will probably be useful.
-Jacob
On Thu, Dec 11, 2008 at 10:52 AM, Jacob Mathew jacobgmat...@gmail.comwrote:
I was under the impression that beans
, Dec 11, 2008 at 4:14 PM, Jacob Mathew jacobgmat...@gmail.comwrote:
The source code for Orchestra provided the answer I was looking for. It
looks like a lock is acquired on the conversationcontext object
corresponding to the request before accessing any of the beans inside of a
conversation. So
I'm looking for documentation on implementing functions that can be
used in EL in jsf pages. Maybe I'm missing something, but the best
info I can find is that the a FunctionMapper object is used to resolve
functions that show up in EL. But how can I define my own
FunctionMapper? how do I set it?
6 matches
Mail list logo
