Nevermind, I should not write emails this early, without an unsend. Servlet A should see same BeanManager as Servlet B, if both servlets are deployed from same war file. That is ApplicationScoped.
On Mon, Nov 11, 2013 at 8:47 AM, John Sarman <[email protected]> wrote: > Ok, I read through your test code, so if you are saying that servlet a > gets same beanmanager as servlet b then yeah thats bad. > > > On Mon, Nov 11, 2013 at 8:44 AM, John Sarman <[email protected]> wrote: > >> 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 >>> >> >> >
