You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by John Sarman <jo...@gmail.com> on 2014/01/09 21:34:30 UTC
Re: New wicket-cdi-1.1 implementation in 6.x
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 <emond.papegaaij@topicus.nl
> 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
> <emond.papegaaij@gmail.com
> > > 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
> <jo...@gmail.com>
> > >
> > > 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
> <jo...@gmail.com>
> > >
> > > 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
> <jo...@gmail.com>
> > > >
> > > > wrote:
> > > > >> On Fri, Nov 22, 2013 at 4:19 PM, Emond Papegaaij <
> > > > >>
> > > > >> emond.papegaaij@gmail.com> wrote:
>
Re: New wicket-cdi-1.1 implementation in 6.x
Posted by John Sarman <jo...@gmail.com>.
Sounds good.
Thanks,
John
On Mon, Jan 13, 2014 at 6:26 AM, Emond Papegaaij <emond.papegaaij@topicus.nl
> wrote:
> John,
>
> It indeed works as the old module did. Igor explained what it was used for
> and I made sure it still works the same. The main usecase is a component
> on a single page instance which requires a conversation. The conversation
> should live as long as the component is on the page.
>
> We also discussed if ConversationalComponent should be changed into an
> annotation. I think it should have been an annotation from the start, but
> changing it now would force users to change their code only for
> aesthetics. The interface works fine, it only looks nicer if it were an
> annotation. So we decided to keep it as is.
>
> Best regards,
> Emond
>
> On Friday 10 January 2014 09:47:46 John Sarman wrote:
> > Emond,
> > Also it is very possible I misinterpreted how cdi-1.0 worked. I
> personally
> > believe that the auto conversation that is started should only end if the
> > propagation rule fails, that is navigate to a new page that is a
> > bookmarkable when propagation is set to NonBookmarkable, I read
> through the
> > cdi-1.0 code and it is basically cut and paste to the rewrite and placed
> at
> > the level so that the conversation is active without needing to use weld
> > internals to activate it :) :) After reading it I may have mistakenly
> > assumed that cdi-1.0 behaved like I described, I have not tested that.
> If
> > that is the case should we bring up a discussing to formally define what
> > semantic controls propagation. That is if you choose to have wicket-cdi
> > manage the conversation then every page needs to implement
> > ConversationalComponent otherwise the conversation will be ended
> even if it
> > passes the propagation criteria. If you choose to manually begin and
> end
> > conversations, then only the propagation criteria dictates conversation
> > propagation.
> >
> > Also we discussed removing the ConversationalComponent and making
> that an
> > Annotation. Is that still on the table?
> >
> > I am very impressed that you were able to remove the required
> dependency of
> > the cdi implementation. Glad you took the lead and made that happen.
> >
> > Thanks
> > John
> >
> > On Fri, Jan 10, 2014 at 8:59 AM, John Sarman <jo...@gmail.com>
> wrote:
> > > Should the Conversation be ended immediately? So if someone uses
> the
> > > ConversationalComponent to automate the conversation.begin(),
> does that
> > > override the propagation if the next page that is navigated to does
> not
> > >
> > > implement ConversationalComponent? I am just trying to understand
> the new
> > >
> > > way of managing the Conversation as it differs from the Wicket Cdi-1.0
> > > pattern. In the 1.0 if a conversation was active and you navigated to
> a
> > > non bookmarkable page (assuming CdiConfiguration is configured with
> the
> > > default nonbookmarkable) then the Conversation would propagate
> > > regardless
> > > if the conversation was automatically managed or manually began. In
> 1.0
> > > if
> > > the conversation was managed by the wicket-cdi and you navigated to
> a
> > > bookmarkable page then wicket-cdi would not propagate the
> Conversation and
> > > call conversation.end().
> > >
> > > Thanks,
> > > John
> > >
> > >
> > >
> > > On Fri, Jan 10, 2014 at 8:49 AM, Emond Papegaaij <
> > >
> > > emond.papegaaij@topicus.nl> wrote:
> > >> The conversation is propagated, but also ended immediately. The
> > >> TestNonConversationalPage is rendered with count = 3, but this
> count is
> > >> lost on the next increment (rendering of the page is a different
> request
> > >> as
> > >> clicking the increment link).
> > >>
> > >> On Friday 10 January 2014 08:38:24 John Sarman wrote:
> > >> > Emond,
> > >> > I understand that. However whether the Conversation is began
> > >>
> > >> manually or
> > >>
> > >> > automatically should not dictate how the Conversation is
> propagated.
> > >> > In
> > >> > the TestConversationalPage starts the conversation via the
> > >> > ConversationalComponent interface then increments the counter.
> The
> > >>
> > >> counter
> > >>
> > >> > increment does not call setResponsePage(). When the next Link is
> > >>
> > >> clicked,
> > >>
> > >> > setResponsePage(new TestNonConversationalPage()); is fired.
> This is a
> > >> >
> > >> > non-bookmarkable page, but the Conversation is not propagated.
> This
> > >>
> > >> means
> > >>
> > >> > that the ConversationPropagation is not working.
> > >> >
> > >> > Thanks,
> > >> > John
> > >> >
> > >> >
> > >> >
> > >> > On Fri, Jan 10, 2014 at 3:02 AM, Emond Papegaaij
> > >>
> > >> <emond.papegaaij@topicus.nl
> > >>
> > >> > > wrote:
> > >> > >
> > >> > > Hi John,
>
Re: New wicket-cdi-1.1 implementation in 6.x
Posted by Emond Papegaaij <em...@topicus.nl>.
John,
It indeed works as the old module did. Igor explained what it was used for
and I made sure it still works the same. The main usecase is a component
on a single page instance which requires a conversation. The conversation
should live as long as the component is on the page.
We also discussed if ConversationalComponent should be changed into an
annotation. I think it should have been an annotation from the start, but
changing it now would force users to change their code only for
aesthetics. The interface works fine, it only looks nicer if it were an
annotation. So we decided to keep it as is.
Best regards,
Emond
On Friday 10 January 2014 09:47:46 John Sarman wrote:
> Emond,
> Also it is very possible I misinterpreted how cdi-1.0 worked. I personally
> believe that the auto conversation that is started should only end if the
> propagation rule fails, that is navigate to a new page that is a
> bookmarkable when propagation is set to NonBookmarkable, I read
through the
> cdi-1.0 code and it is basically cut and paste to the rewrite and placed
at
> the level so that the conversation is active without needing to use weld
> internals to activate it :) :) After reading it I may have mistakenly
> assumed that cdi-1.0 behaved like I described, I have not tested that. If
> that is the case should we bring up a discussing to formally define what
> semantic controls propagation. That is if you choose to have wicket-cdi
> manage the conversation then every page needs to implement
> ConversationalComponent otherwise the conversation will be ended
even if it
> passes the propagation criteria. If you choose to manually begin and
end
> conversations, then only the propagation criteria dictates conversation
> propagation.
>
> Also we discussed removing the ConversationalComponent and making
that an
> Annotation. Is that still on the table?
>
> I am very impressed that you were able to remove the required
dependency of
> the cdi implementation. Glad you took the lead and made that happen.
>
> Thanks
> John
>
> On Fri, Jan 10, 2014 at 8:59 AM, John Sarman <jo...@gmail.com>
wrote:
> > Should the Conversation be ended immediately? So if someone uses
the
> > ConversationalComponent to automate the conversation.begin(),
does that
> > override the propagation if the next page that is navigated to does
not
> >
> > implement ConversationalComponent? I am just trying to understand
the new
> >
> > way of managing the Conversation as it differs from the Wicket Cdi-1.0
> > pattern. In the 1.0 if a conversation was active and you navigated to
a
> > non bookmarkable page (assuming CdiConfiguration is configured with
the
> > default nonbookmarkable) then the Conversation would propagate
> > regardless
> > if the conversation was automatically managed or manually began. In
1.0
> > if
> > the conversation was managed by the wicket-cdi and you navigated to
a
> > bookmarkable page then wicket-cdi would not propagate the
Conversation and
> > call conversation.end().
> >
> > Thanks,
> > John
> >
> >
> >
> > On Fri, Jan 10, 2014 at 8:49 AM, Emond Papegaaij <
> >
> > emond.papegaaij@topicus.nl> wrote:
> >> The conversation is propagated, but also ended immediately. The
> >> TestNonConversationalPage is rendered with count = 3, but this
count is
> >> lost on the next increment (rendering of the page is a different
request
> >> as
> >> clicking the increment link).
> >>
> >> On Friday 10 January 2014 08:38:24 John Sarman wrote:
> >> > Emond,
> >> > I understand that. However whether the Conversation is began
> >>
> >> manually or
> >>
> >> > automatically should not dictate how the Conversation is
propagated.
> >> > In
> >> > the TestConversationalPage starts the conversation via the
> >> > ConversationalComponent interface then increments the counter.
The
> >>
> >> counter
> >>
> >> > increment does not call setResponsePage(). When the next Link is
> >>
> >> clicked,
> >>
> >> > setResponsePage(new TestNonConversationalPage()); is fired.
This is a
> >> >
> >> > non-bookmarkable page, but the Conversation is not propagated.
This
> >>
> >> means
> >>
> >> > that the ConversationPropagation is not working.
> >> >
> >> > Thanks,
> >> > John
> >> >
> >> >
> >> >
> >> > On Fri, Jan 10, 2014 at 3:02 AM, Emond Papegaaij
> >>
> >> <emond.papegaaij@topicus.nl
> >>
> >> > > wrote:
> >> > >
> >> > > Hi John,
Re: New wicket-cdi-1.1 implementation in 6.x
Posted by John Sarman <jo...@gmail.com>.
Emond,
Also it is very possible I misinterpreted how cdi-1.0 worked. I personally
believe that the auto conversation that is started should only end if the
propagation rule fails, that is navigate to a new page that is a
bookmarkable when propagation is set to NonBookmarkable, I read through the
cdi-1.0 code and it is basically cut and paste to the rewrite and placed at
the level so that the conversation is active without needing to use weld
internals to activate it :) :) After reading it I may have mistakenly
assumed that cdi-1.0 behaved like I described, I have not tested that. If
that is the case should we bring up a discussing to formally define what
semantic controls propagation. That is if you choose to have wicket-cdi
manage the conversation then every page needs to implement
ConversationalComponent otherwise the conversation will be ended even if it
passes the propagation criteria. If you choose to manually begin and end
conversations, then only the propagation criteria dictates conversation
propagation.
Also we discussed removing the ConversationalComponent and making that an
Annotation. Is that still on the table?
I am very impressed that you were able to remove the required dependency of
the cdi implementation. Glad you took the lead and made that happen.
Thanks
John
On Fri, Jan 10, 2014 at 8:59 AM, John Sarman <jo...@gmail.com> wrote:
> Should the Conversation be ended immediately? So if someone uses the
> ConversationalComponent to automate the conversation.begin(), does that
> override the propagation if the next page that is navigated to does not
> implement ConversationalComponent? I am just trying to understand the new
> way of managing the Conversation as it differs from the Wicket Cdi-1.0
> pattern. In the 1.0 if a conversation was active and you navigated to a
> non bookmarkable page (assuming CdiConfiguration is configured with the
> default nonbookmarkable) then the Conversation would propagate regardless
> if the conversation was automatically managed or manually began. In 1.0 if
> the conversation was managed by the wicket-cdi and you navigated to a
> bookmarkable page then wicket-cdi would not propagate the Conversation and
> call conversation.end().
>
> Thanks,
> John
>
>
>
> On Fri, Jan 10, 2014 at 8:49 AM, Emond Papegaaij <
> emond.papegaaij@topicus.nl> wrote:
>
>> The conversation is propagated, but also ended immediately. The
>> TestNonConversationalPage is rendered with count = 3, but this count is
>> lost on the next increment (rendering of the page is a different request
>> as
>> clicking the increment link).
>>
>> On Friday 10 January 2014 08:38:24 John Sarman wrote:
>> > Emond,
>> > I understand that. However whether the Conversation is began
>> manually or
>> > automatically should not dictate how the Conversation is propagated. In
>> > the TestConversationalPage starts the conversation via the
>> > ConversationalComponent interface then increments the counter. The
>> counter
>> > increment does not call setResponsePage(). When the next Link is
>> clicked,
>> > setResponsePage(new TestNonConversationalPage()); is fired. This is a
>> > non-bookmarkable page, but the Conversation is not propagated. This
>> means
>> > that the ConversationPropagation is not working.
>> >
>> > Thanks,
>> > John
>> >
>> >
>> >
>> > On Fri, Jan 10, 2014 at 3:02 AM, Emond Papegaaij
>> <emond.papegaaij@topicus.nl
>> > > wrote:
>> > >
>> > > Hi John,
>> > >
>> > > You are mixing two concepts here: conversation propagation and
>> auto-
>> > > conversations. These two operate separately. Auto-conversations are
>> > > started _and_ ended automatically. You can use this, for example, on a
>> > > page where a conversational component is added and later removed
>> > > again. The conversation will stay active for as long as the component
>> is
>> > > on
>> > > the page. If you wish to take control of an auto-conversation, you
>> need to
>> > > inject AutoConversation and call setAutomatic(false).
>> > >
>> > > Best regards,
>> > > Emond
>> > >
>> > > On Thursday 09 January 2014 15:34:30 John Sarman wrote:
>> > > > 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
>>
>
>
Re: New wicket-cdi-1.1 implementation in 6.x
Posted by John Sarman <jo...@gmail.com>.
Should the Conversation be ended immediately? So if someone uses the
ConversationalComponent to automate the conversation.begin(), does that
override the propagation if the next page that is navigated to does not
implement ConversationalComponent? I am just trying to understand the new
way of managing the Conversation as it differs from the Wicket Cdi-1.0
pattern. In the 1.0 if a conversation was active and you navigated to a
non bookmarkable page (assuming CdiConfiguration is configured with the
default nonbookmarkable) then the Conversation would propagate regardless
if the conversation was automatically managed or manually began. In 1.0 if
the conversation was managed by the wicket-cdi and you navigated to a
bookmarkable page then wicket-cdi would not propagate the Conversation and
call conversation.end().
Thanks,
John
On Fri, Jan 10, 2014 at 8:49 AM, Emond Papegaaij <emond.papegaaij@topicus.nl
> wrote:
> The conversation is propagated, but also ended immediately. The
> TestNonConversationalPage is rendered with count = 3, but this count is
> lost on the next increment (rendering of the page is a different request as
> clicking the increment link).
>
> On Friday 10 January 2014 08:38:24 John Sarman wrote:
> > Emond,
> > I understand that. However whether the Conversation is began
> manually or
> > automatically should not dictate how the Conversation is propagated. In
> > the TestConversationalPage starts the conversation via the
> > ConversationalComponent interface then increments the counter. The
> counter
> > increment does not call setResponsePage(). When the next Link is
> clicked,
> > setResponsePage(new TestNonConversationalPage()); is fired. This is a
> > non-bookmarkable page, but the Conversation is not propagated. This
> means
> > that the ConversationPropagation is not working.
> >
> > Thanks,
> > John
> >
> >
> >
> > On Fri, Jan 10, 2014 at 3:02 AM, Emond Papegaaij
> <emond.papegaaij@topicus.nl
> > > wrote:
> > >
> > > Hi John,
> > >
> > > You are mixing two concepts here: conversation propagation and
> auto-
> > > conversations. These two operate separately. Auto-conversations are
> > > started _and_ ended automatically. You can use this, for example, on a
> > > page where a conversational component is added and later removed
> > > again. The conversation will stay active for as long as the component
> is
> > > on
> > > the page. If you wish to take control of an auto-conversation, you
> need to
> > > inject AutoConversation and call setAutomatic(false).
> > >
> > > Best regards,
> > > Emond
> > >
> > > On Thursday 09 January 2014 15:34:30 John Sarman wrote:
> > > > 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
>
Re: New wicket-cdi-1.1 implementation in 6.x
Posted by Emond Papegaaij <em...@topicus.nl>.
The conversation is propagated, but also ended immediately. The
TestNonConversationalPage is rendered with count = 3, but this count is
lost on the next increment (rendering of the page is a different request as
clicking the increment link).
On Friday 10 January 2014 08:38:24 John Sarman wrote:
> Emond,
> I understand that. However whether the Conversation is began
manually or
> automatically should not dictate how the Conversation is propagated. In
> the TestConversationalPage starts the conversation via the
> ConversationalComponent interface then increments the counter. The
counter
> increment does not call setResponsePage(). When the next Link is
clicked,
> setResponsePage(new TestNonConversationalPage()); is fired. This is a
> non-bookmarkable page, but the Conversation is not propagated. This
means
> that the ConversationPropagation is not working.
>
> Thanks,
> John
>
>
>
> On Fri, Jan 10, 2014 at 3:02 AM, Emond Papegaaij
<emond.papegaaij@topicus.nl
> > wrote:
> >
> > Hi John,
> >
> > You are mixing two concepts here: conversation propagation and
auto-
> > conversations. These two operate separately. Auto-conversations are
> > started _and_ ended automatically. You can use this, for example, on a
> > page where a conversational component is added and later removed
> > again. The conversation will stay active for as long as the component
is
> > on
> > the page. If you wish to take control of an auto-conversation, you
need to
> > inject AutoConversation and call setAutomatic(false).
> >
> > Best regards,
> > Emond
> >
> > On Thursday 09 January 2014 15:34:30 John Sarman wrote:
> > > 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
Re: New wicket-cdi-1.1 implementation in 6.x
Posted by John Sarman <jo...@gmail.com>.
Emond,
I understand that. However whether the Conversation is began manually or
automatically should not dictate how the Conversation is propagated. In
the TestConversationalPage starts the conversation via the
ConversationalComponent interface then increments the counter. The counter
increment does not call setResponsePage(). When the next Link is clicked,
setResponsePage(new TestNonConversationalPage()); is fired. This is a
non-bookmarkable page, but the Conversation is not propagated. This means
that the ConversationPropagation is not working.
Thanks,
John
On Fri, Jan 10, 2014 at 3:02 AM, Emond Papegaaij <emond.papegaaij@topicus.nl
> wrote:
> Hi John,
>
> You are mixing two concepts here: conversation propagation and auto-
> conversations. These two operate separately. Auto-conversations are
> started _and_ ended automatically. You can use this, for example, on a
> page where a conversational component is added and later removed
> again. The conversation will stay active for as long as the component is on
> the page. If you wish to take control of an auto-conversation, you need to
> inject AutoConversation and call setAutomatic(false).
>
> Best regards,
> Emond
>
> On Thursday 09 January 2014 15:34:30 John Sarman wrote:
> > 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
> <emond.papegaaij@topicus.nl
> > > 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
> > >
> > > <emond.papegaaij@gmail.com
> > >
> > > > > 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
> > >
> > > <jo...@gmail.com>
> > >
> > > > > 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
>
Re: New wicket-cdi-1.1 implementation in 6.x
Posted by Emond Papegaaij <em...@topicus.nl>.
Hi John,
You are mixing two concepts here: conversation propagation and auto-
conversations. These two operate separately. Auto-conversations are
started _and_ ended automatically. You can use this, for example, on a
page where a conversational component is added and later removed
again. The conversation will stay active for as long as the component is on
the page. If you wish to take control of an auto-conversation, you need to
inject AutoConversation and call setAutomatic(false).
Best regards,
Emond
On Thursday 09 January 2014 15:34:30 John Sarman wrote:
> 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
<emond.papegaaij@topicus.nl
> > 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
> >
> > <emond.papegaaij@gmail.com
> >
> > > > 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
> >
> > <jo...@gmail.com>
> >
> > > > 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