I have found a issue, that makes the second point necessary to implement:
If one uses a conversation scoped bean in an expression, which is evaluated
during restore view as part of a tag handler (e.g. in c:forEach), we need
the conversation already to be restored, because otherwise two conversations
will be in action during one request: one from the beginning the request
till after restore view phase, and another one (the "right" one actually) in
the other phases.
Because before restore view no view and therefore no cid is available (well,
sound reasonable ;) our only chance is to retrieve the cid from something
else. The current implementation attaches the cid to every form's action url
due to ConversationAwareViewHandler, so we could use this information for
restoring the conversation. Does anybody has objections or a better solution
regarding this point in mind?
br, Sven
2009/11/15 Gurkan Erdogdu <gurkanerdo...@yahoo.com>
> Hi Sven;
>
> Very good points :) I will try to correct those issues.
>
> PS: If you would like to patch, you are always welcome :)
>
> Thanks again for helping us!
>
> --Gurkan
>
>
>
>
> ________________________________
> From: Sven Linstaedt <sven.linsta...@googlemail.com>
> To: openwebbeans-dev@incubator.apache.org
> Sent: Sun, November 15, 2009 4:02:57 PM
> Subject: Review of WebBeansPhaseListener
>
> Hi,
>
> I have some questions about the JSF integration of OWB, which come to my
> mind when dealing with the source code:
>
> _ JSF PhaseListener have to be threadsafe (see JSF 2.0 spec, chapter
> 12.3.),
> but WebBeansPhaseListener references a obvious context dependent
> conversation. A quick look at mojarra indicates there is a singleton
> instantiated for each PhaseListener, so I supose WebBeansPhaseListenerwill
> get into troubles when serving multiple requests. -> Use a ThreadLocal
> instead?
>
> _ Conversation scoped beans might be accessed *during* restore view during
> a
> FaceletHandler evaluation. But the ConversationContext is restored *after*
> restore view. -> Are there any limitations or drawbacks restoring the
> ConversationContext *before* restore view? Weld is also doing this as far
> as
> I remember.
>
> _ Make sure the ViewRoot's initial state is marked *before* modifying it's
> attributes, because otherwise the stored information may be lost.
>
> _ WebBeansPhaseListener.fromRedirect ThreadLocal seems not to be resetted
> anywhere. Furthermore the initializer of this ThreadLocal is done once (?)
> in a static block, and not per created Thread using something like
>
> public static ThreadLocal<Boolean> fromRedirect = new
> ThreadLocal<Boolean>()
> {
> protected Boolean initialValue() {
> return false;
> }
> }
>
> In addition, if this static field is public, it should at least be final.
>
>
> br, Sven
>
>
>
>
>
