[weld-dev] proper handling of Events for beans in inactive Contexts?

Fri Apr 9 10:48:33 EDT 2010

Thanks Pete, maybe we need a 3rd state?

* Reception.ALWAYS which would throw the ContextNotActiveException
* Reception.IF_EXISTS which only sends if the context is active and an instance exists
* Reception.CREATE_IF_ACTIVE will create an instance if the context is active

just an idea ...

This may get more important if portable 3rd party contexts pop up and get used heavily in the future.

LieGrue,
strub

--- Pete Muir <pmuir at redhat.com> schrieb am Fr, 9.4.2010:

> Von: Pete Muir <pmuir at redhat.com>
> Betreff: Re: [weld-dev] proper handling of Events for beans in inactive Contexts?
> An: "Pete Muir" <pmuir at redhat.com>
> CC: "Mark Struberg" <struberg at yahoo.de>, weld-dev at lists.jboss.org
> Datum: Freitag, 9. April, 2010 16:43 Uhr
> Mark has pointed out that for
> Reception.ALWAYS he agrees that an exception should be
> thrown, but that for Reception.IF_EXISTS he thinks that an
> exception should not be thrown. I agree this is certainly a
> nicer way for the programmer to work (and is semantically
> correct IMO).
> 
> I think the spec should be clarified to state that this the
> case, in the meantime we will implement this in Weld.
> 
> https://jira.jboss.org/jira/browse/WELD-480
> 
> On 9 Apr 2010, at 15:04, Pete Muir wrote:
> 
> > I believe it's fairly clear that a
> ContextNotActiveException will be thrown. Hence why we are
> all addressing ways to get around your problem rather than
> what the spec requirements are ;-)
> > 
> > Why do you think it isn't clear?
> > 
> > On 9 Apr 2010, at 14:02, Mark Struberg wrote:
> > 
> >> 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 at gmail.com>
> schrieb am Fr, 9.4.2010:
> >> 
> >> Von: Nicklas Karlsson <nickarls at gmail.com>
> >> Betreff: Re: [weld-dev] proper handling of Events
> for beans in inactive Contexts?
> >> An: "Sven Linstaedt" <sven.linstaedt at googlemail.com>
> >> CC: "Mark Struberg" <struberg at yahoo.de>,
> "Pete Muir" <pmuir at redhat.com>,
> weld-dev at 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 at 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 at 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 at redhat.com>
> schrieb am Fr, 9.4.2010:
> >> 
> >>> Von: Pete Muir <pmuir at redhat.com>
> >>> Betreff: Re: [weld-dev] proper handling of
> Events for beans in inactive Contexts?
> >>> An: "Mark Struberg" <struberg at yahoo.de>
> >>> CC: weld-dev at 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.
> >>>> http://mail.yahoo.com
> >>>> 
> >>>>
> _______________________________________________
> >>>> weld-dev mailing list
> >>>> weld-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/weld-dev
> >>> 
> >>> 
> >> 
> >>
> __________________________________________________
> >> 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/weld-dev
> >> 
> >> 
> >> _______________________________________________
> >> weld-dev mailing list
> >> weld-dev at 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
> > 
> > 
> > _______________________________________________
> > weld-dev mailing list
> > weld-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/weld-dev
> 
> 

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com 