Hi Sven; AFAIK, conversation is defined for using it in pure JSF in the specification. I do not know whether it supports tag handlers or not.
--Gurkan 2009/11/23 Sven Linstaedt <[email protected]> > 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 <[email protected]> > > > 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 <[email protected]> > > To: [email protected] > > 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 > > > > > > > > > > > -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
