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