I was looking at your bug, but in the case you specified where the cached
BeanManager is passed, seems to be the correct behavior because the
CdiConfiguration is ApplicationScoped. The CDI class states this:
/**
* Get the CDI BeanManager for the current context
*
* @return
*/
public abstract BeanManager getBeanManager();
So the cached BeanManager passed back is because it is accessed in an
ApplicationScoped class. ApplicationScoped != Wickets Application scope.
On Mon, Nov 11, 2013 at 8:26 AM, Emond Papegaaij <[email protected]
> wrote:
> 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
>
