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