You are right, InitialContext.lookup was returning null. I've fixed it by falling back to CDI.current().getBeanManager() in that case. The workaround is needed because of a very nasty bug in de Wildfly-Weld integration: https://issues.jboss.org/browse/WFLY-2481
Best regards, Emond On Monday 11 November 2013 08:18:20 John Sarman wrote: > As far as the Test failing, I think the workaround code to use jndi first > may have caused the test to fail. So far it seems that all the request > pull 50 is not in the 6 branch. > What forced the need for the workaround? > > John > > On Mon, Nov 11, 2013 at 8:00 AM, John Sarman <[email protected]> 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
