This was just one example!
My point was that the spec should clearly define what will happen if a context is not
active at the time the event get's sent.
Exchange @ConversationScoped with @ViewScoepd in my example. This context is only
available after the ViewMap got restored. And there is no way to move the ViewMap
restoration into a ServletListener.
So there will be situations where we have to deal with this situation somehow.
LieGrue,
strub
--- Nicklas Karlsson <nickarls(a)gmail.com> schrieb am Fr, 9.4.2010:
Von: Nicklas Karlsson <nickarls(a)gmail.com
Betreff:
Re: [weld-dev] proper handling of Events for beans in inactive Contexts?
An: "Sven Linstaedt" <sven.linstaedt(a)googlemail.com
CC: "Mark Struberg" <struberg(a)yahoo.de>,
"Pete Muir" <pmuir(a)redhat.com>, weld-dev(a)lists.jboss.org
Datum: Freitag, 9. April, 2010 14:52 Uhr
You could use a similar construct like Seam 2 had, the ContextualHttpServletRequest which
essentially enabled the contexts and then you did your work i an overloaded method but the
problem is portability between CDI implementations for context activation. Or if you could
just move conversation management to a servlet listener. I mailed the EG on both issues so
let's see what comes back from that direction.
On Fri, Apr 9, 2010 at 3:31 PM, Sven Linstaedt <sven.linstaedt(a)googlemail.com>
wrote:
As far as I remember, conversation contexts are not available in servlet filters (at least
in seam version 2.x). Because conversation definition is currently tied to JSF lifecycle,
the best approach from my experience is avoid servlet filter (and others) and only use JSF
extension points like phase listeners.
br, Sven
2010/4/9 Mark Struberg <struberg(a)yahoo.de
Sorry, I don't really get it.
If you have a 'transient conversation' and you like to send an event to BeanX and
there is no contextual instance of that BeanX already in your transient conversation
context, then a new one will get created and the event will get received by this
contextual instance.
However, a few nanoseconds later the restoreView phase will restore the ViewRoot and we
find a cid=4711 there. So we will now lookup this context with cid=4711 and oops, this
already contains a contextual instance of BeanX which DIDN'T get the event!
So what is the transient conversation really doing? What is it for?
Sometimes a context may return isActive() == false and this has a very good reason! Doing
any trickery in such cases will imo cause more problems than they solve.
LieGrue,
strub
--- Pete Muir <pmuir(a)redhat.com> schrieb am Fr, 9.4.2010:
Von: Pete Muir <pmuir(a)redhat.com>
Betreff: Re: [weld-dev] proper handling of Events for beans in
inactive Contexts?
An: "Mark Struberg" <struberg(a)yahoo.de>
CC: weld-dev(a)lists.jboss.org
Datum: Freitag, 9. April, 2010 11:37 Uhr
Tricky situation, and something we
"fixed" in Seam by having a transient conversation always
active. I have a feeling that is what CDI should do to.
On 25 Mar 2010, at 16:49, Mark Struberg wrote:
> Hi!
>
> I have the following scenario:
>
> *) A ServletFilter fires a UserLoggedInEvent
> *) A @ConversationScoped MyBean @Observes
UserLoggedInEvent with Reception.ALWAYS
>
> The problem here is that the Conversation is not yet
'opened' at the time the ServletFilter fires that event.
Thus ConversationContext.isActive() == false and I cannot
create this bean.
>
> A similar situation appears if you try to send an
event to a @ViewScoped bean from a JSF phase where the
ViewMap doesn't yet exist.
>
> So since there is no way to create a contextual
instance, the obvious solution is to not send the
notification to this very bean.
>
> I didn't find this covered in the spec and I don't yet
see much we can do in this case. This may cause some not so
obvious behaviour and user may wonder why they don't get the
event.
>
> So, should we log some info in this case or silently
swallow it?
>
>
> txs and LieGrue,
> strub
>
>
> __________________________________________________
> Do You Yahoo!?
> Sie sind Spam leid? Yahoo! Mail verfügt über einen
herausragenden Schutz gegen Massenmails.
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen
Massenmails.
http://mail.yahoo.com
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
--
---
Nik
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen
Massenmails.
http://mail.yahoo.com