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 >> > > >> > >> > >
