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: > >> > >>> On Fri, Nov 22, 2013 at 9:45 PM, John Sarman <[email protected]> > >>> wrote: > >>> > >>> > NonContextual.of(application.getClass()).postConstruct(application); > >>> > Why call postConstruct and not inject? It does inject but also calls > >>> > the @PostContruct methods, which would be called after init. Seems > >>> > like Applications should not support @PostConstuct. > >>> > > >>> > >>> This came from the old implementation. I'd rather not break that. > >>> > >>> What about converting ConversationalComponent to an annotation versus > >>> > an empty interface? > >>> > > >>> > >>> I agree. The interface can be marked deprecated, maybe even removed, > and > >>> be > >>> replaced by an @Inherited annotation. There is one minor issue with > >>> @Inherited annotations: they are not inherited through interfaces, but > I > >>> don't think that's a problem for this usecase. > >>> > >>> Also how you activating the ConversationalContext? I see the > >>> > weld-impl was removed, is there a generic way of doing this? > >>> > >>> > >>> CDI 1.1 specifies that conversations are propagated via the cid query > >>> parameter. So, as long as this parameter is set correctly, there's no > >>> need > >>> to manually (de)activate the conversational context. > >>> > >> > >> I understand that but in ConversationPropagator when you have the > >> @ConversationScoped AutoConversation, that object will be associated > with > >> the auto activated context which is not associated with the CID until > you > >> do it manually. That was the reason for the Weld impl. > >> > >>> > >>> Emond > >>> > >>> > >>> > On Fri, Nov 22, 2013 at 4:18 AM, Emond Papegaaij < > >>> > [email protected] > >>> > > wrote: > >>> > > >>> > > Hi all, > >>> > > > >>> > > I've just merged the changes to the wicket-cdi-1.1 module back to > >>> > > wicket-6.x. In short, the following things changed compared to the > >>> 1.0 > >>> > > module: > >>> > > - CDI 1.1 is required > >>> > > - Conversation propagation is always done via a cid query > >>> parameter, as > >>> > > specified in JSR-346, and is portable > >>> > > - No dependencies on any CDI implementation > >>> > > - Injection in all Wicket classes (components, behaviors, session > >>> and > >>> > > application) cannot be disabled > >>> > > - Some testcases > >>> > > - NonContextualManager is removed > >>> > > - NonContextual performance is greatly improved via caching > >>> > > > >>> > > One important thing that did not change is to make the application > >>> > > managed. It turns out this is close to impossible. As it is right > >>> now, > >>> > you > >>> > > cannot initialize the application via a route other than > Filter.init. > >>> > > Therefore, > >>> > > CDI cannot do the initialization and can only produce uninitialized > >>> > > applications, which is dangerous. > >>> > > > >>> > > I tried to add more testcases, but it turns out that the request > >>> handling > >>> > > done by WicketTester is rather incompatible with CDI. For example, > >>> > > WicketTester instantiates pages, even if you redirect bookmarkable. > >>> Also, > >>> > > it > >>> > > builds urls in a very different way than components do, causing the > >>> cid > >>> > > parameters to be incorrect or missing. > >>> > > > >>> > > It would be nice if others using wicket-cdi could review the > changes > >>> I've > >>> > > made. We do use wicket-cdi, but we don't use conversations that > >>> much. We > >>> > > mostly use it for injection. > >>> > > > >>> > > Best regards, > >>> > > Emond > >>> > > > >>> > > >>> > >> > >> > > >
