Re: [weld-dev] Question about conversations scope initilization obeserver

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 I found: On a fresh start of the sever I ping the url with a nonsense cid. ConversationBean will call conversation.begin() in the try block. This triggers a codepath that leads to LazyHttpConversationContextImpl.checkContextInitialized() line 124, that line will throw an exception. We go back out to ConversationBean where the exception is caught. Then when the catch block calls conversation.begin() it will once again reach LazyHttpConversationContextImpl.checkContextInitialized() but this time the if statement on line 121 returns true and so we never call initialize(). In both cases it is the same LazyHttpConversationContextImpl. I also put a breakpoint in the observer and pinged the URL without manually specificing a cid. From inside the observer method I can see that LazyHttpConversationContextImpl.checkContextInitialized() line 128 is on the stack. So to summarise. When I call the url with a nonsense cdi: The try block reaches checkContextInitialized and gets an exception on line 121. Then the catch block reaches checkContextInitialized and does nothing because isInitialized() returns true. Thus neither attempt reaches line 128 and the observer method is never fied. This feels like a bug to me, not just because the observer isn't fired but also because if the initilization method had an exception half way though 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 90 so that the exception takes place before initilized is set to true. Of course that assumes that running initilized twice won't cause worse problems. What do you think? Is this a bug? From: Matej Novotny <manovotn(a)redhat.com&gt; To: Benjamin Confino <BENJAMIC(a)uk.ibm.com&gt; Cc: Takayuki T Ishii <EBB0F3L(a)jp.ibm.com&gt;, weld-dev(a)lists.jboss.org Date: 28/01/2020 15:03 Subject: [EXTERNAL] Re: [weld-dev] Question about conversations scope initilization obeserver Hello, 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()[1] will blow up with NonExistingConversationException and you will jump right into the catch block[2] where you begin a conversation with given ID, but you no longer invoke the bean, hence the context won't get activated. Try adding the `bean.getMsg()` call to the catch block and see if that helps. Note that CDI spec sets no requirements on how/when to activate the conversation context, so the lazy behaviour is compliant with spec (and this is also why you saw no such test in TCKs). Regards Matej _________________________________________________________________________________ [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_mano... [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_mano... ----- Original Message ----- obeserver To the restarting classes https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A9080_Conv... to see the https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A9080_Conv... to see https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse-2... it already with we're number https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail... 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU