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