Emond,
I finally had some time to go over the cdi rewrite and I on the first test
I was reviewing I do not think the Conversation propagation is working
correctly. In the test Class ConversationPropagatorTest, the first
test testAutoConversationNonBookmarkable uses the Wicket
page TestConversationalPage which extends ConversationalComponent to notify
the framework the conversations should be managed automatically. The
initial for loop iterates through the increment clicks to verify
the TestConversationBean counter is incremented properly. This works fine.
Then the test clicks the next link, which goes to a non bookmarkable page
that also injects the TestConversationBean. At this point
the TestConversationBean current count should be equal to the last
increment from the first page, but it is 0. The increment link is clicked
on that page and the count is incremented to 1, and every call after that
the TestConversationBean is reinjected but not part of the conversation so
the count is 0 then 1 and the test asserts (1) not the continuous
incremented count. I realize that the test passes, but I think the test on
the second for loop should read
tester.clickLink("increment");
tester.assertCount(i); // The value of i continues to increment from the
first for loop.
I have not went through the code yet, but it seems that as soon as next
page that does not implement the ConversationalComponent interface,
although it is a nonbookmarkable page, the conversation is not propagated.
My understanding of how Igor built 1.0 was that the
ConversationalComponent could be used to automate the code to begin a
Conversation if one was not already active and the propagation was a method
to continue the conversation based on the way a page was created. That is
if a conversation was active and the next page in the pipeline was a
nonbookmarkable page then the conversation was propagated regardless if it
implemented ConversationalComponent (assuming CDIConfiguration propagation
was set to NONBOOKMARKABLE) . I will continue to debug through the code to
determine why the conversation was not propagated, but please let me know
if I am not seeing eye to eye with how the code handles propagation.
Thanks,
John
On Thu, Dec 12, 2013 at 2:23 AM, Emond Papegaaij <[email protected]
> wrote:
> This issue, we discussed earlier, is fixed. Propagation of the conversation
> works fine now.
>
> On Wednesday 11 December 2013 12:40:44 John Sarman wrote:
> > Emond,
> > Have you had a chance to work on the propagation code?
> >
> > Thanks,
> > John
> >
> >
> > On Mon, Nov 25, 2013 at 11:14 AM, Emond Papegaaij
> <[email protected]
> > > wrote:
> > >
> > > I've found the problem. It has nothing to do with associating a
> > > conversation. The problem is that first all links are rendered, and
> only
> > > then the conversation is marked long-running. The auto-begin and
> auto-end
> > > methods need to be moved to a IComponentInstantiationListener, so
> the
> > > conversation can be started before the links are
> > > rendered. onRequestHandlerExecuted simply is too late. I'll see if I
> can
> > > fix that tomorrow.
> > >
> > > Best regards,
> > > Emond
> > >
> > >
> > > On Fri, Nov 22, 2013 at 11:31 PM, John Sarman
> <[email protected]>
> > >
> > > wrote:
> > > > Emond,
> > > > If you want to quick test execute the code in a debugger and look
> at the
> > > > Conversation object in the ConversationPropagator. You will find
> that
> > > > is
> > > > always transient even when a Cid is passed over URL, unless you call
> > > > begin(), once you associate that Conversation would become non
> transient
> > > > assuming CID was set. Look back at Igor's code and follow through
> to
> > > > associate, you will notice that Igor never touches the
> autoConversation
> > > > object until he calls conversation.begin() for starting, or
> associates
> > > > to
> > > > an existing conversation then calls conversation.end() when
> > > > autoEndIfNecessary.
> > > >
> > > > John
> > > >
> > > >
> > > > On Fri, Nov 22, 2013 at 5:15 PM, John Sarman
> <[email protected]>
> > >
> > > wrote:
> > > > > Emond,
> > > > > I updated the wicket-example on my local checkout of latest 6.x to
> use
> > > >
> > > > the
> > > >
> > > > > cdi-1.1. The conversation propagation is working as expected
> due to
> > >
> > > the
> > >
> > > > > CID. I set the configuration to Nonbookmarkable, and it worked
> due to
> > >
> > > the
> > >
> > > > > CID. However, when I change the example to use the
> > > >
> > > > ConversationalComponent
> > > >
> > > > > to perform auto conversation management, it does not work. To
> test I
> > > > > Inject the AutoConversation in the ConversationPage1 and output
> > > > > the autoConversation.isAutomatic(). This should return true since
> I
> > > > > implemented ConversationalComponent, but it returns false. I
> also
> > >
> > > added
> > >
> > > > > @inject Conversation conversation on the test page. The
> conversation
> > >
> > > is
> > >
> > > > > transient.
> > > > >
> > > > > I believe this is because after you call conversation.begin in the
> > > > > autoBeginIfNecessary you have to then associate that CID to the
> > > > > conversationContext of the implementation container. I dont
> think
> > > > > ConversationPropagator is automatically associated with the
> > >
> > > conversation,
> > >
> > > > > because it is instantiated at application.init(), and not during
> the
> > > > > Request, so the instance of autoConversation is not magically
> > >
> > > associated
> > >
> > > > > with the request until it is done manually. I'm doing more tests,
> > > >
> > > > because
> > > >
> > > > > I would love to not need to include a container specific impl, but
> I
> > > >
> > > > afraid
> > > >
> > > > > we either have to drop auto conversational support or add a impl
> like
> > > > > original design.
> > > > >
> > > > > John
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Nov 22, 2013 at 4:30 PM, John Sarman
> <[email protected]>
> > > >
> > > > wrote:
> > > > >> On Fri, Nov 22, 2013 at 4:19 PM, Emond Papegaaij <
> > > > >>
> > > > >> [email protected]> wrote:
>
