I reread the code, and I see what it is used for. CdiWebApplicationFactory can use a bit of a cleanup. For example, Instance has methods to check for satisfaction and ambiguity. Also, I think this should be rewritten as an all-or-nothing solution. You either use CdiWicketFilter with CdiWebApplicationFactory or you don't. This should greatly reduce the amount of code and should allow for more robust error checking.
Best regards, Emond On Monday 11 November 2013 08:00:10 John Sarman wrote: > It is not a forced requirement, just an option for full cdi injection. > > > On Mon, Nov 11, 2013 at 3:50 AM, Emond Papegaaij <[email protected] > > wrote: > > > > Hi John, > > > > I've just merged the pull request in the wicket-6.x branch (still under > > experimental). The version still is 0.2-SNAPSHOT, as the versions are > > automatically increased on release. The reason I've merged the pull > > request is to give us all a common baseline to discuss. Could you please > > verify I did not break anything merging it? All testcases but one pass. > > The > > failing testcase (CdiConfigurationTest.testMultiAppLoad) tries to access > > the > > BeanManager from an unmanaged thread, resulting in an NPE. > > > > I've already noticed one aspect I do not like: the requirement to annotate > > your app with @WicketApp. With a Producer method, it should be possible > > to use the actual application names, without the requirement to duplicate > > them on your application class. > > > > Best regards, > > Emond > > > > On Sunday 10 November 2013 16:44:28 John Sarman wrote: > > > 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 > >
