Edmond, On July, I worked vigorously to get to the 0.3 snapshot, which was what I consider the first beta ready version of the move to cdi1.1. The 0.1 and 0.2 snapshot was 0.1, getting it to work and learning how to request pull requests. 0.2 was adding some slight fixes and testing. After that I realized that I was treating the @ApplicationScoped as same scope that ThreadContext gives to a Wicket App. That is entirely wrong. So the previous version only properly supports at most 1 Wicket app, the second could override the Configuration of the first (not acceptable). In my 0.3 version, I added the code to prevent that, by using the Wicket app key generated as the key to the configuration properties for an app. This allows for multiple Wicket apps to be deployed in a Servlet. However, for whatever reason, that checkin could not properly merge into the 7 branch. I have to remedy this even if I just have to copy paste the code, to make git happy ( I blame myself, not Git). In the meantime, I recommend looking at my latest (albeit broken) pull request https://github.com/apache/wicket/pull/50 and port that version. It adds thorough testing, fixes the multiple deploy issue, reintroduces the auto Conversation, and extends the ConversationalComponent by introducing the @Conversational, which by default works the same as the Cdi-1.0 ConverationalComponent, but also allows the propagation and auto feature to be modified for an Object that uses the annotation, without affecting the global defaults set during Configuration. The 0.3 also introduces the CdiWicketFilter. The CdiWicketFilter allows the configuration settings to be managed in web.xml. It also instantiates the WicketApplication using Cdi so that the Application is injected before the init() method. The changes do not break the original Cdi-1.0, initialization technique, to support the backwards compatibility.
John On Sat, Nov 9, 2013 at 3:29 PM, Emond Papegaaij <[email protected]>wrote: > In wicket 6, this code also still is in experimental. The reason I ported > it to Wicket 6, was to actually use it. wicket-cdi (the old module), is > usable with 1.1, but not very optimal. One of the main problems with the > old implementation is the amount of InjectionTargets created. The annoying > warnings will probably be fixed in Weld ( > https://issues.jboss.org/browse/WELD-1547), but the fact remains that > InjectionTargets are very expensive to create and should be cached. Another > thing I like about the new module is that it actually uses CDI, not just > makes it available in Wicket. Also, the integration requires a lot less > code in a container that uses Weld (like Wildfly). > > I do agree that the code is far from ready. For example, I don't think > entire packages should be ignored. Also, I don't like how settings like > auto-conversations are injected. I do like that CDI is used for that, but > I'd rather see a configuration object with a @Producer method for all > settings at once. Having the code in wicket 6 allows me to work on these > issues. I do not expect our current application to be ported to Wicket 7 > any time soon, but we are migrating to CDI 1.1 on Wildfly. > > Best regards, > Emond > > > On Fri, Nov 8, 2013 at 10:10 PM, John Sarman <[email protected]> wrote: > > > +1 removal > > > > Never should have been merged into the 6 branch and not the 7 until there > > is a consensus. > > > > > > On Fri, Nov 8, 2013 at 4:07 PM, Igor Vaynberg <[email protected] > > >wrote: > > > > > not sure why this was merged into 6.x but there are a lot of problems > > > with this contribution as can be seen here [1]. > > > > > > i think this should be removed from at least the release branch. > > > > > > -igor > > > > > > [1] https://github.com/apache/wicket/pull/50#issuecomment-28063112 > > > > > >
