Thank you for the fix, I tested it and it worked perfectly. I also created
a pull request to backport it to 2.4: https://github.com/weld/core/pull/1964
which has also worked locally for me.
My client is currently on CDI-1.2/Weld-2.4 so even if you don't want to
patch 2.4 at this point I may need to give them a one-of patch until they
are ready to move up to CDI-2.0; so if there's any fatal flaw in that backport
please let me know.
Matej Novotny <firstname.lastname@example.org>
Benjamin Confino <BENJAMIC@uk.ibm.com>
Takayuki T Ishii <EBB0F3L@jp.ibm.com>,
[weld-dev] Question about conversations scope initilization
so after some tedious debugging (and fair amount of time figuring out how
lazy conversation work in this case) I managed to get to the state you
I think this is a bug - Weld doesn't fire @Initialized event in case where
user attempts to restore non-existing conversation.
We correctly associate the request with new conversation before the exception
is thrown (which is what spec requires and tests) but we don't fire the
Issue is here - https://issues.redhat.com/browse/WELD-2611
And I've proposed a fix here - https://github.com/weld/core/pull/1962
If you could try that and tell me if it works, that would be great.
Although I did use the same reproducer, so hopefully it'll work ;-)
Regards and have a nice weekend!
----- Original Message -----
> From: "Benjamin Confino" <BENJAMIC@uk.ibm.com>
> To: "Matej Novotny" <email@example.com>
> Cc: "Takayuki T Ishii" <EBB0F3L@jp.ibm.com>, firstname.lastname@example.org
> Sent: Friday, January 31, 2020 1:20:50 AM
> Subject: RE: [weld-dev] Question about conversations scope initilization
> Hello Matej
> After testing adding a call to `bean.getMsg` in the catch block, the
> behaviour is unchanged. I did some further digging and here's what
> On a fresh start of the sever I ping the url with a nonsense cid.
> ConversationBean will call conversation.begin() in the try block.
> triggers a codepath that leads to
> LazyHttpConversationContextImpl.checkContextInitialized() line 124,
> line will throw an exception. We go back out to ConversationBean where
> exception is caught. Then when the catch block calls conversation.begin()
> it will once again reach
> LazyHttpConversationContextImpl.checkContextInitialized() but this
> the if statement on line 121 returns true and so we never call
> initialize(). In both cases it is the same
> I also put a breakpoint in the observer and pinged the URL without
> manually specificing a cid. From inside the observer method I can
> LazyHttpConversationContextImpl.checkContextInitialized() line 128
> the stack.
> So to summarise. When I call the url with a nonsense cdi: The try
> reaches checkContextInitialized and gets an exception on line 121.
> the catch block reaches checkContextInitialized and does nothing because
> isInitialized() returns true. Thus neither attempt reaches line 128
> the observer method is never fied.
> This feels like a bug to me, not just because the observer isn't fired
> also because if the initilization method had an exception half way
> is it left in a good state? I don't know enough about these weld internals
> to check.
> It occurs to me that one possible fix is to swap line 89 with line
> that the exception takes place before initilized is set to true. Of
> that assumes that running initilized twice won't cause worse problems.
> What do you think? Is this a bug?
> From: Matej Novotny <email@example.com>
> To: Benjamin Confino <BENJAMIC@uk.ibm.com>
> Cc: Takayuki T Ishii <EBB0F3L@jp.ibm.com>, firstname.lastname@example.org
> Date: 28/01/2020 15:03
> Subject: [EXTERNAL] Re: [weld-dev] Question
> scope initilization obeserver
> I think I know what is the "problem" here.
> Weld uses lazy conversation init - that means we don't activate context
> until you try and access a conversation scoped bean.
> Now, in your example, the ConversationBean tries to begin() a
> conversation, then calls the bean (which initializes the context and
> notifies the observer).
> However, in the situation where you try and pass in a non-existing
> conversation, the invocation to conversation.begin() will blow
> NonExistingConversationException and
> you will jump right into the catch block where you begin a conversation
> with given ID, but you no longer invoke the bean, hence the context
> get activated.
> Try adding the `bean.getMsg()` call to the catch block and see if
> Note that CDI spec sets no requirements on how/when to activate the
> conversation context, so the lazy behaviour is compliant with spec
> this is also why you saw no such test in TCKs).
> ----- Original Message -----
> > From: "Benjamin Confino" <BENJAMIC@uk.ibm.com>
> > To: "Matej Novotny" <email@example.com>
> > Cc: "Takayuki T Ishii" <EBB0F3L@jp.ibm.com>,
> > Sent: Tuesday, January 28, 2020 12:06:14 PM
> > Subject: RE: [weld-dev] Question about conversations scope initilization
> > Hello
> > Thanks for the link. I had a look but I couldn't find any TCK
> > checking to see if an observer method will catch the new
> > ConversationContext being created for the "new transient
> > check if a new conversation was activated I created an entirely
> > server and ran the test application on it, the behaviour was
> > first url I pinged on this new server ended with "cid="
and the observer
> > didn't . Normally I've just been restarting the old server but
> > frequently.
> > I've attached the recreate you requested. it consists of the
> > attached to my previous email as well as a minimal html page.
To run it
> > load it onto your server and ping
> to see the
> > observer fire, and
> to see
> > the observer fail to fire.
> > Best regards
> > Benjamin
> > From: Matej Novotny <firstname.lastname@example.org>
> > To: Benjamin Confino <BENJAMIC@uk.ibm.com>
> > Cc: email@example.com, Takayuki T Ishii
> > Date: 27/01/2020 11:39
> > Subject: [EXTERNAL] Re: [weld-dev]
Question about conversations
> > scope initilization obeserver
> > Hello,
> > I'd start by pointing you to CDI TCK as that's a good starting
> > see what's covered.
> > For your question, that would be this test -
> > And possibly few more in the same test class.
> > As for the linked classes - your `ConversationBean` is listening
> > @Initialized event. Can you verify that a new conversation was
> > for your request instead of verifying that context was activated?
> > E.g. check IDs or something along those lines? I suppose that
> > true and in that case it works just as spec requires it to.
> > From the top of my head I don't really know how we activate/deactivate
> > ConversationContext, I'd need to dig that up, but looking at
> > doesn't mandate that it is activated every time again and it
> > be active for given request.
> > Plus from just the classes you linked, I cannot know if you test
> > no existing conversation or maybe with some long running one
> > try to send a request for non-existing one...and so on.
> > So if the above doesn't is not enough to answer your question,
> > going to need a complete reproducer so that we both talk about
> > scenario :)
> > Matej
> > ----- Original Message -----
> > > From: "Benjamin Confino" <BENJAMIC@uk.ibm.com>
> > > To: firstname.lastname@example.org
> > > Cc: "Takayuki T Ishii" <EBB0F3L@jp.ibm.com>
> > > Sent: Monday, January 27, 2020 11:42:14 AM
> > > Subject: [weld-dev] Question about conversations scope initilization
> > obeserver
> > >
> > > Hello
> > >
> > > I have a customer who's sent me a sample application, I
> > the
> > > source to it below.
> > >
> > > When the customer visits index.xhtml they see the following
> > >
> > > Conversation initialized.
> > > Conversation begun. cid:1
> > > Conversation destroyed. cid:1
> > >
> > > However when they append "?cdi=" or a non-existnant
> > > "?cdi=10000" to the url they do not see "Conversation
> > >
> > > The CDI spec says that: If the propagated conversation cannot
> > restored,
> > > the container must associate the request with a new transient
> > conversation
> > > and throw an exception of type
> > > javax.enterprise.context.NonexistentConversationException.
> > >
> > > I'm wondering if this should apply here? Or would it only
apply if the
> > cid
> > > pointed to an existing conversation that could not be restored?
> > there
> > > anything in the spec that covers this specific situation?
> > >
> > > Unless stated otherwise above:
> > > IBM United Kingdom Limited - Registered in England and Wales
> > > 741598.
> > > Registered office: PO Box 41, North Harbour, Portsmouth,
> > 3AU
> > >
> > > _______________________________________________
> > > weld-dev mailing list
> > > email@example.com
> > >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6