9:54 a.m.
Thank you Matej,
I will report this info back to my client, hopefully they will be
satisfied with this answer.
Best regards
Benjamin
From: Matej Novotny <manovotn(a)redhat.com>
To: Benjamin Confino <BENJAMIC(a)uk.ibm.com>
Cc: Takayuki T Ishii <EBB0F3L(a)jp.ibm.com>, 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 -----
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
From: "Benjamin Confino" <BENJAMIC(a)uk.ibm.com>
To: "Matej Novotny" <manovotn(a)redhat.com>
Cc: "Takayuki T Ishii" <EBB0F3L(a)jp.ibm.com>, weld-dev(a)lists.jboss.org
Sent: Tuesday, January 28, 2020 12:06:14 PM
Subject: RE: [weld-dev] Question about conversations scope initilization
obeserver
Hello
Thanks for the link. I had a look but I couldn't find any TCK tests
checking to see if an observer method will catch the new
ConversationContext being created for the "new transient conversation".
To
check if a new conversation was activated I created an entirely
fresh
server and ran the test application on it, the behaviour was the same,
the
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
restarting
frequently.
I've attached the recreate you requested. it consists of the three
classes
attached to my previous email as well as a minimal html page. To run
it
load it onto your server and ping
https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A9080_Conv...
to see the
observer fire, and
https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A9080_Conv...
to see
the observer fail to fire.
Best regards
Benjamin
From: Matej Novotny <manovotn(a)redhat.com>
To: Benjamin Confino <BENJAMIC(a)uk.ibm.com>
Cc: weld-dev(a)lists.jboss.org, Takayuki T Ishii <EBB0F3L(a)jp.ibm.com>
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 point to
see what's covered.
For your question, that would be this test -
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse-2...
And possibly few more in the same test class.
As for the linked classes - your `ConversationBean` is listening for
@Initialized event. Can you verify that a new conversation was activated
for your request instead of verifying that context was activated?
E.g. check IDs or something along those lines? I suppose that will hold
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 CDI spec,
it
doesn't mandate that it is activated every time again and it
could
already
be active for given request.
Plus from just the classes you linked, I cannot know if you test this
with
no existing conversation or maybe with some long running one before
you
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, then
we're
going to need a complete reproducer so that we both talk about the
same
scenario :)
Matej
----- Original Message -----
> From: "Benjamin Confino" <BENJAMIC(a)uk.ibm.com>
> To: weld-dev(a)lists.jboss.org
> Cc: "Takayuki T Ishii" <EBB0F3L(a)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 have attached
the
> source to it below.
> When the customer visits index.xhtml they see the
following output:
> Conversation initialized.
> Conversation begun. cid:1 , timeout:3600000
> Conversation destroyed. cid:1
> However when they append "?cdi=" or a
non-existnant identifier like
> "?cdi=10000" to the url they do not see "Conversation
initialized."
> The CDI spec says that: If the propagated conversation
cannot be
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? And is
there
> anything in the spec that covers this specific situation?
> 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
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail...
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