Conversations, Injections, Wicket and Ajax - Strange Behaviour
Dear Seam Users,
Hopefully somebody can help explain this seemingly odd behaviour that I've seen with AJAX requests using Wicket.
Essentially, Conversations and Conversation-scoped beans are being created when they shouldn't.
The most basic example of this which I've yet to strip down completely) there is a Form, within which there is an AjaxButton with an onSubmit(target) method.
I've added lots of trace info printing out the various details, which I will show now with some description.
First the request to a bookmarkable page via entering the url into the address bar. (No conversation propagation)
18:00:38,471 INFO [STDOUT] ***************************************************** 18:00:38,472 INFO [STDOUT] *** @Create-ing manager object hashCode: 1783935998 cid:311 18:00:38,472 INFO [STDOUT] ***************************************************** 18:00:38,476 DEBUG [ConversationListenerReport] Conversation Started 18:00:38,974 WARN [AddNewChannel] onDetach() -> Rendered WebPage with Conversation ID: 311 (LRC: true) 18:00:38,975 WARN [AddNewChannel] onDetach() -> Rendered WebPage with Conversation ID: 311 (LRC: true)
In the above output we can see the SEAM POJO @Scope(ScopeType.Conversation) being created prior to injection into the wicket page @In(create=true)
The ConversationListenderReport is just an observer for LRC's beginning, which is started by the SEAM bean.
The page is rendered fine and the Page onDetach() method prints the conversation details.
OK, No problems here. There is a long running conversation with ID 311.
Next, The following output is the result of a single click on the AjaxButton.
18:00:45,139 INFO [STDOUT] ***************************************************** 18:00:45,139 INFO [STDOUT] *** @Create-ing manager object hashCode: 178165655 cid:329 18:00:45,139 INFO [STDOUT] ***************************************************** 18:00:45,139 INFO [STDOUT] after super.OnPageAttached() -> injectedObject is not null: true 18:00:45,142 INFO [STDOUT] after super.OnPageAttached() -> injectedObject: 178165655 18:00:45,142 INFO [STDOUT] after super.OnPageAttached() -> Conversation - id: 329 pid: null rid: 329 lrc: false 18:00:45,146 INFO [STDOUT] AjaxButton.onSubmit() -> Conversation id:311 long-running: true 18:00:45,148 INFO [STDOUT] AjaxButton.onSubmit() -> injected Manager hashcode: 178165655 18:00:45,148 WARN [AddNewChannel] onDetach() -> Rendered WebPage with Conversation ID: 311 (LRC: true) 18:00:45,150 INFO [STDOUT] after super.onDetach() -> injected object hashcode: 178165655 18:00:45,152 WARN [AddNewChannel] onDetach() -> Rendered WebPage with Conversation ID: 311 (LRC: true) 18:00:45,155 INFO [STDOUT] after super.onDetach() -> injected object hashcode: 178165655
Here we see that for some reason a new SEAM bean is being made and it thinks it is in Conversation ID no.329.
I've overridden onPageAttached() to inspect a bit of this lifecycle, and here we see that the page has had
the freshly created SEAM Bean injected in - This is not expected.
Furthermore, this is happening in a new fresh temporary conversation.
Moreover, next when the button's onClick() is performed IT thinks it is back in Conversation 311 but has a reference
to Conversation 329's SEAM Bean.
Finally when the page's onDetach() is run, the page now think's it is back on the old Conv, but has a reference
to the SEAM Bean constructed on the new Conv.
I'm baffeld by this - suffice to say it only happens in some cases - I'm trying to find a small example of Good and Bad.
Is there anyway I could have programmed this to get this behaviour?
Thanks for any input.
Rob.
Note. All conversation ID's are result of printing Conversation.instance().getId() directly.