Emond, Looks good.
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. What about converting ConversationalComponent to an annotation versus an empty interface? Also how you activating the ConversationalContext? I see the weld-impl was removed, is there a generic way of doing this? John 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 >
